I’m running my openHAB3 on a raspberry Pi and after a while I got the SNMP agent running on it and I can read out information.
Right now I have some basic information like uptime, load, memory cached/buffered/free and so on. Is there some other key indicators I should look out for especially for running openHAB? or did someone already setup a monitoring of OH3?
Any reason why you don‘t use the systeminfo binding ?
Also, have you seen the Metrics add-on?
Yes, I want external monitoring. If for some reason my openhab server won’t respond, I won’t get any info from a binding within.
…and I tried nagios/zabbix, which is a big too heavy for my use case…
I’ll take a look, thanks.
This one sounds really, really good! only downside is the formatting of “Prometheus”-syntax. I tried to parse the output into a decent JSON, but the Prometheus syntax is not really well structured. Is there a configuration I can reach, where the output is more structured?
# HELP jvm_threads_daemon_threads The current number of live daemon threads
# TYPE jvm_threads_daemon_threads gauge
jvm_threads_daemon_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",} 149.0
# HELP jvm_buffer_count_buffers An estimate of the number of buffers in the pool
# TYPE jvm_buffer_count_buffers gauge
jvm_buffer_count_buffers{id="direct",metric="openhab.core.metric.jvm",openhab_core_metric="true",} 216.0
jvm_buffer_count_buffers{id="mapped",metric="openhab.core.metric.jvm",openhab_core_metric="true",} 0.0
# HELP jvm_threads_states_threads The current number of threads having TIMED_WAITING state
# TYPE jvm_threads_states_threads gauge
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="new",} 0.0
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="terminated",} 0.0
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="runnable",} 58.0
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="timed-waiting",} 141.0
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="waiting",} 110.0
jvm_threads_states_threads{metric="openhab.core.metric.jvm",openhab_core_metric="true",state="blocked",} 0.0
# HELP jvm_memory_max_bytes The maximum amount of memory in bytes that can be used for memory management
# TYPE jvm_memory_max_bytes gauge
jvm_memory_max_bytes{area="nonheap",id="Metaspace",metric="openhab.core.metric.jvm",openhab_core_metric="true",} -1.0
jvm_memory_max_bytes{area="heap",id="G1 Eden Space",metric="openhab.core.metric.jvm",openhab_core_metric="true",} -1.0
jvm_memory_max_bytes{area="nonheap",id="CodeCache",metric="openhab.core.metric.jvm",openhab_core_metric="true",} 3.3554432E7
jvm_memory_max_bytes{area="heap",id="G1 Survivor Space",metric="openhab.core.metric.jvm",openhab_core_metric="true",} -1.0
jvm_memory_max_bytes{area="heap",id="G1 Old Gen",metric="openhab.core.metric.jvm",openhab_core_metric="true",} 2.68435456E8
# HELP executor_queued_tasks The approximate number of tasks that are queued for execution
# TYPE executor_queued_tasks gauge
executor_queued_tasks{metric="openhab.core.metric.threadpools",name="ConfigStatusService",openhab_core_metric="true",pool="ConfigStatusService",} 0.0
executor_queued_tasks{metric="openhab.core.metric.threadpools",name="thingHandler",openhab_core_metric="true",pool="thingHandler",} 75.0
executor_queued_tasks{metric="openhab.core.metric.threadpools",name="discovery",openhab_core_metric="true",pool="discovery",} 4.0
...
Problem is, there’s duplicate keys everywhere, e.g. “jvm_buffer_count_buffers” and they reveal their real identity only in the attributes, e.g. id - but then “jvm_threads_states_threads” uses state and not as first attribute,… that’s a pain in the a… to convert into a decent JSON-format for further use…