<div dir="ltr">All,<div>This is an operational question, i.e. how to pin point alerts and co.</div><div><div><br></div><div>I monitor process queues and get the longest queue with Recon, using:</div><div><font face="monospace, monospace">recon:proc_count(message_queue_len, 1).</font></div><div><br></div><div>I'm using <font face="monospace, monospace">exometer_core</font> to send data to HostedGraphite. <br></div><div><br></div><div>Tonight I received errors stating that the queue exceeded this number, and this is the queue info that Recon gives me:</div><div><font face="monospace, monospace">[exometer_report_graphite,{current_function,{prim_inet,send,3}},{initial_call,{proc_lib,init_p,3}}]<br></font></div><div><br></div><div>I got reports every 5 seconds (the interval of time used by exometer to report) from around 00:30 until 08:20, with a message queue growing from a few hundreds to 6k or so. After 08:20, the queue went back to 0.</div><div><br></div><div>I can see that my server was up (no other errors, all functionalities and pings were correct during the same period). Therefore, it looks to me that exometer was unable to send the data to the HostedGraphite servers during the whole period 00:30 - 08:20, and when it was able to it emptied the queue that went then back to normal.</div><div><br></div><div>However: HostedGraphite only has a "hole" of data from around 07:40 until 08:20, i.e. not the whole period where the queue kept growing.</div><div><br></div><div>Therefore, my questions is: Is <font face="monospace, monospace">exometer_core</font> performing some local cache, i.e. if it's unable to send data it will retry? And if so, is this cache limited? Otherwise I don't see what could be causing the queue lenght of <span style="font-family:monospace,monospace">exometer_report_graphite </span>to grow. But if this is so, then why am I seeing a hole in data?</div><div><br></div></div><div>Than kyou,</div><div>r.</div><div><br></div></div>