-
Notifications
You must be signed in to change notification settings - Fork 104
PANIC: runtime error: invalid memory address or nil pointer dereference #811
Comments
@Dieterbe, seems that this looks the same as old issue where opening root namespace in grafana query editor crash the nodes |
for an instance that crashes like this, have you run any specific index related commands such as metric deletes? if not, this looks like there's some corrupt state in your index, specifically some child node is nil. we could also write a custom utility that reads your index, and analyzes the index around where the problem lies, and that should reveal the problem, but that would be custom development work. |
thanks @Dieterbe , We will discuss it here this week to see how to handle. |
@Dieterbe , here is the log output (now in the right place):
|
that log output is not as helpful as what you posted in #812 because this one doesn't show any errors.
most likely the problem is those metrics are malformed, as mentioned in the other ticket. 2 things need to happen:
|
We push metrics directly to Kafka and also through carbon-relay-ng. While getting the patch from you we used it to prevent crashes and we also started to put safeties where needed. In our code that write directly and with blacklists in carbon. From what I saw , bad metrics came from both directions This is my carbon-relay-ng blacklist:
|
good news. with raintank/fakemetrics#9 i was able to trivially reproduce.
our options are:
in this process i also found out not only does graphite allow 1 leading dot, it seems to allow an unlimited amount, and will just chomp them all of. it also reduces sequences of dots in the middle of metric keys, so the previous fix for carbon (#694) will have to be improved. creating a new ticket, #1008 to track this |
graphite allows them, but our backends should be more strict see grafana/metrictank#811
version : 0.7.4_633_gd5ca2bcb-1
The text was updated successfully, but these errors were encountered: