Log level flag not picked up - "-log.level=debug"

[ajohnstone]

Seeing issues with the graphite exporter, but cannot increase log level to debug.

ps aufx

# root
root     26891  0.2  0.4 1509540 35768 pts/0   Sl   Jul27  11:40 /usr/bin/docker -d
100      21292  0.1  0.1  45888 11096 ?        Ssl  10:59   0:04  \_ /bin/graphite_exporter -log.level=debug -graphite.mapping-config=/etc/graphite/graphite_mapping.conf

# container
docker exec -it 6869f5dde41e ps aufx
PID   USER     TIME   COMMAND
    1 golang     0:04 /bin/graphite_exporter -log.level=debug -graphite.mapping-config=/etc/graphite/graphite_mapping.conf

Container logs

docker logs f0d4533b7560
time="2015-07-30T12:07:02Z" level=info msg="Starting Server: :9108" file=main.go line=240 

docker compose

graphiteexporter:
  command: -log.level=debug -graphite.mapping-config=/etc/graphite/graphite_mapping.conf
  image: prom/graphite-exporter
  ports:
  - "9108:9108"
  - "9109:9109"
  - "9109/udp:9109/udp"
  volumes:
  - "graphiteexporter/conf:/etc/graphite"

Levels

docker run -it prom/graphite-exporter -h
Usage of /bin/graphite_exporter:
  -graphite.listen-address=":9109": TCP and UDP address on which to accept samples.
  -graphite.mapping-config="": Metric mapping configuration file name.
  -graphite.sample-expiry=5m0s: How long a sample is valid for.
  -log.level=info: Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal, panic].
  -web.listen-address=":9108": Address on which to expose metrics.
  -web.telemetry-path="/metrics": Path under which to expose Prometheus metrics.

[brian-brazil]

In what way does it appear the flag isn't being picked up?

The graphite exporter doesn't have any logs at the debug level.

[ajohnstone]

I scanned the code after and realised that it does not have any logs at debug level.
I think it was my misinterpretation of what I was looking at.

However finding it very difficult to debug the application at present.

[yotamoron]

I agree with @ajohnstone - my Prometheus instance is RSTing the tcp connection with no logs or warnings what so ever.

[LuboVarga]

I had also same problem. No logs and resetting of connections to monitored machine. I have thought that reset is due many packets with bad checksums.

Finally I have found that problem is in declaring multiple metrics under same name (actually two histogram instances with same name). I have also created commit which adds test to missing feature which will warn users in such case. LuboVarga/client_java@9a501e0