Since I installed munin and enabled alerts, it has been intermittently sending me this for four of my hard drives:
WARNINGs: smartctl_exit_status is 4.00 (outside range [:1]).
The munin documentation says:
The ignoreexit parameter can be useful to exclude some bits in smartctl exit code, which is a bit mask described in its main page, from consideration.
So I added the following to /etc/munin/plugin-conf.d/munin-node:
[smart_sdg;smart_sdh;smart_sdi;smart_sdj]
env.ignoreexit 4
(Note that this corresponds with the four drives sending the alerts.)
Alas, the alerts keep coming. I can't make them stop and I don't understand why. Is my config location wrong? Am I doing the configuration wrong? Why isn't this working? Any help?
It turns out that I had an old version of Munin and it doesn't support the env.ignoreexit parameters. I grabbed the latest version of the plugin from Munin's repository and it seems to work.
This was a fun exploration. I wish Munin threw errors when you gave it configurations it didn't recognize, but alas.
Related
My original carbon storage-schema config was set to 10s:1w, 60s:1y and was working fine for months. I've recently updated it to 1s:7d, 10s:30d, 60s,1y. I've resized all my whisper files to reflect the new retention schema using the following bit of bash:
collectd_dir="/opt/graphite/storage/whisper/collectd/"
retention="1s:7d 1m:30d 15m:1y"
find $collectd_dir -type f -name '*.wsp' | parallel whisper-resize.py \
--nobackup {} $retention \;
I've confirmed that they've been updated using whisper-info.py with the correct retention and data points. I've also confirmed that the storage-schema is valid using a storage-schema validation script.
The carbon-cache{1..8}, carbon-relay, carbon-aggregator, and collectd services have been stopped before the whisper resizing, then started once the resizing was complete.
However, when checking in on a Grafana dashboard, I'm seeing empty graphs with correct data points (per sec, but no data) on collectd plugin charts; but with the graphs that are providing data, it's showing data and data points every 10s (old retention), instead of 1s.
The /var/log/carbon/console.log is looking good, and the collectd whisper files all have carbon user access, so no permission denied issues when writing.
When running an ngrep on port 2003 on the graphite host, I'm seeing connections to the relay, along with metrics being sent. Those metrics are then getting relayed to a pool of 8 caches to their pickle port.
Has anyone else experienced similar issues, or can possibly help me diagnose the issue further? Have I missed something here?
So it took me a little while to figure this out. It had nothing to do with the local_settings.py file like some of the old responses, but it had to do with the Interval function in the collectd.conf.
A lot of the older responses mentioned that you needed to include 'Interval 1' inside each Plugin container. I think this would have been great due to the control of each metric. However, that would create config errors in my logs, and break the metric. Setting 'Interval 1' at top level of the config resolved my issues.
Im hoping someone could help me please. I am trying to retrieve time and date from the Sim800L and I am coming short. I have a Sim800L here and I am communicating with it successfully over the Arduino IDE. I have used the following AT commands as suggested online with the following results.
AT+CCLK?
+CCLK: "04/01/01,03:59:51+00"
OK
AT+CLTS=1
OK
AT&W
OK
AT+CLTS?
+CLTS: 1
OK
After restarting, the date and time however is not set to network time. The network is a national carrier and should be able to do this.
AT+CCLK?
+CCLK: "04/01/01,03:59:51+00"
OK
Any ideas?
Thank you
I found the same trouble. in this page embedded world i Found something that works for me. it is add the following instruction
AT&W
Read current time (You can see that the time is not right):
AT+CCLK?
+CCLK: "04/01/01,00:14:12+22"
OK
Enable auto network time sync :
AT+CLTS=1
OK
Check if value is set :
AT+CLTS?
+CLTS: 1
OK
Save the setting to permanent memory so that module enables sync on restart also :
AT&W
OK
Restart the module and check time :
AT+CCLK?
+CCLK: "18/06/21,12:00:21+22"
OK
and it is all.
You do correct but
Base on "SIM800 Series_AT Command Manual_V1.09" Edited on 2015-08-03
in page 154 in "6.2.12 AT+CLTS Get Local Timestamp" section
"Support for this Command will be network dependent."
Change your network provider
In the UK, "AT+CCLK?" usually works (the network sets this time) IF using a network-branded-SIM (eg. EE or O2 branded). However for SOME MVNO-SIMs (Mobile Virtual Network Operators SIMS) "AT+CCLK?" does NOT work (even where the same network-branded-SIM does).
Under these cases (for my SIM800L), if you need a valid time (for example so you can send a GPRS-email with a valid time-stamp), you have to manually set the time using: AT+CCLK="21/10/15,18:55:00+04"
I don't have any errors with my smart target application, but I do see in the event log, the following error messages:
ERROR 2012-09-19 14:30:09
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is
up and running)
and:
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out java.util.concurrent.TimeoutException at
java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at
java.util.concurrent.FutureTask.get(Unknown Source) at
com.tridion.smarttarget.tags.TimeoutQueryRunner.executeQuery(TimeoutQueryRunner.java:64)
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out
I would really like to understand what is causing these and how I can remove them. Or some suggested steps to help me debug this would be great :)
As I say, everything is working perfectly, later on in the logs I see the query to ST is correct and the results being generated.
In the event that is helps, I'm running on a 2009 implementation with Smart Target 2010, java 1.5.
thanks
John
Sounds like you might have a trigger configured in ST that does not actually exist in the ADF (or is mismatched). Have you looked through your trigger-types.xml file for anything obvious? Have you disabled an ADF cartridge but not removed the corresponding trigger in the XML perhaps? See the documentation for Defining trigger types.
I think your timeout is coming from the SmartTarget region rather than FredHopper. Sometimes a query that isn't already cached in FredHopper can take a while to return, even though it's ultimately successful. The ST query tag has a timeout (defined in the smarttarget_conf.xml file, or over-ridden with a tag attribute) that it will wait for a response from Fredhopper for before resorting to using the fallback content. This might explain why you see later in the logs that the query is correct and that results are returned. See the documentation for <tcdl:query>.
No conclusive answer for you I'm afraid, but I hope that helps.
The first error is logged if your SmartTarget cartridge is not running -- or if the data that it puts into ADF is lost somehow (e.g. you have disabled sessions in your web server).
In that case, SmartTarget will still do a query but it won't include anything from the Ambient Data Framework in it. If you don't have any triggers based on ambient data, the end result is the same for you.
To get rid of the error, make sure that smarttarget_cartridge is configured correctly.
As for the timeout error, it simply means that the query sent to Fredhopper took longer than the configured time. In that case it will show the fallback content instead. If this is happening a lot, you might want to increase the timeout within smarttarget_conf.xml.
I hope you found the issue, but for future reference, the first error message is raised when the claim "taf:claim:ambientdata:definedtriggertypes" is not set by the SmartTarget cartridge. This can be caused by:
SmartTarget cartridge could not load the the trigger types from the SmartTarget server. The log will show an error "can't retrieve list of defined trigger types from FH".
The HTTP session on your web server is expired during an active visit (the HTTP session expired but the browser is still open) and the claim is "lost".
The server does not support sessions like Peter mentioned.
I'm getting the following the error message in my content delivery logging:
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is up and running)
I've checked out my smarttarget_conf.xml and have confirmed the web services are up and running. The one that is failing (or returns a 404 via broswer) is the following:
<Endpoint>http://servername:8180/fredhopper/config/trigger-types</Endpoint>
But having read through the documentation and the forum, i'm under the impression this is correct and that the url doesn't respond to GET requests.
So I'm assuming everything is set up correctly, in my smarttarget_conf.xml, I'm hoping is anyone has some pointers for me to have a look into to resolve this issue.
Thanks in advance.
Solution
The issue here is that my trigger-types.xml file was not correctly formed on the FAS (Fredhopper server). I'm giving Jeremy the winning answer below as he spotted my issue behind the scenes.
Thanks Jeremy - I hope anyone reading this up-votes your answer
The port of my local SmartTarget instance is 8180, not 8080. Perhaps this is the same for you?
Setting up eucalyptus cloud on my laptop has become a nightmare for me.
When I run the command euca-describe-availability-zones, it shows up as expected. It shows all free/max values correctly. However, when I run euca-run-instance it says that no resources av.
How can this be fixed?
you are not giving enough information to really understand what the problem is. If you check on the sticky post at http://open.eucalyptus.com/forums/eucalyptus-support-0 for generic info needed. In your case, can you post the output of euca-describe-availability-zones verbose (ran with the admin credentials) and the output of euca-describe-addresses (again with admin credentials)?
cheers
graziano