当前位置: 首页 > 工具软件 > 91 Monitor > 使用案例 >

【logstash】logstash monitor

饶承宣
2023-12-01

logstash 提供了四种api用于监控:

  • Node Info API
  • Plugins Info API
  • Node Stats API
  • Hot Threads API

在logstash启动后,我们可以通过访问9600端口,curl -XGET 'localhost:9600/?pretty',获取logstash的基本信息。

{
   "host": "logstash.1",
   "version": "5.6.16",
   "http_address": "127.0.0.1:9600"
}

默认logstash启动时会绑定9600端口,如果要启动多个logstash实例,可以通过命令行参数--http.port,来修改绑定port。

node info

curl -XGET 'localhost:9600/_node/<types>'节点信息API检索有关节点的信息。<types>是可选的,指定要返回的节点信息的类型。

可以通过逗号分隔组合以下任何类型来限制返回的信息:

typedesc
pipeline获取特定于管道的信息和设置。
os获取有关OS的节点级信息。
jvm获取节点级JVM信息,包括有关线程的信息。

plugin info

curl -XGET 'localhost:9600/_node/plugins?pretty'插件信息API获取有关当前安装的所有Logstash插件的信息。此API基本上返回运行bin/logstash-plugin list –verbose命令的输出。

stats info

curl -XGET 'localhost:9600/_node/stats/<types>'获取logstash 运行时状态。<types>是可选的,有以下取值:

typedesc
jvm获取JVM统计信息,包括有关线程,内存使用情况,垃圾收集器和正常运行时间的统计信息。
process获取进程统计信息,包括有关文件描述符,内存消耗和CPU使用率的统计信息。
pipeline获取有关Logstash管道的运行时统计信息。
reloads获取有关配置重新加载成功和失败的运行时统计信息。
os当Logstash在容器中运行时,获取有关cgroup的运行时统计信息。

hot thread

curl -XGET 'localhost:9600/_node/hot_threads?pretty'热线程API获取Logstash的当前热线程。热线程是一个Java线程,它具有较高的CPU使用率并且执行时间超过正常时间。

一个热线程例子:

{
    "time": "2017-01-12T12:09:45-08:00",
    "busiest_threads": 3,
    "threads": [
      {
        "name": "LogStash::Runner",
        "percent_of_cpu_time": 1.07,
        "state": "timed_waiting",
        "traces": [
          "java.lang.Object.wait(Native Method)",
          "java.lang.Thread.join(Thread.java:1253)",
          "org.jruby.internal.runtime.NativeThread.join(NativeThread.java:75)",
          "org.jruby.RubyThread.join(RubyThread.java:697)",
          "org.jruby.RubyThread$INVOKER$i$0$1$join.call(RubyThread$INVOKER$i$0$1$join.gen)",
          "org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:663)",
          "org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:198)",
          "org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:306)",
          "org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:136)",
          "org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:60)"
        ]
      },
      {
        "name": "[main]>worker7",
        "percent_of_cpu_time": 0.71,
        "state": "waiting",
        "traces": [
          "sun.misc.Unsafe.park(Native Method)",
          "java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)",
          "java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)",
          "org.jruby.RubyThread.lockInterruptibly(RubyThread.java:1470)",
          "org.jruby.ext.thread.Mutex.lock(Mutex.java:91)",
          "org.jruby.ext.thread.Mutex.synchronize(Mutex.java:147)",
          "org.jruby.ext.thread.Mutex$INVOKER$i$0$0$synchronize.call(Mutex$INVOKER$i$0$0$synchronize.gen)"
        ]
      },
      {
        "name": "[main]>worker3",
        "percent_of_cpu_time": 0.71,
        "state": "waiting",
        "traces": [
          "sun.misc.Unsafe.park(Native Method)",
          "java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)",
          "java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)",
          "java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)",
          "org.jruby.RubyThread.lockInterruptibly(RubyThread.java:1470)",
          "org.jruby.ext.thread.Mutex.lock(Mutex.java:91)",
          "org.jruby.ext.thread.Mutex.synchronize(Mutex.java:147)",
          "org.jruby.ext.thread.Mutex$INVOKER$i$0$0$synchronize.call(Mutex$INVOKER$i$0$0$synchronize.gen)"
        ]
      }
    ]
  }
}
url参数描述
threads要返回的热线程数。默认值为3。
human如果为true,则返回纯文本而不是JSON格式。默认值为false。
ignore_idle_threads如果为true,则不返回空闲线程。默认值为true。

这四种api会返回实时结果,如果要持续监控,可以考虑使用 xpack的monior UI。

logging

除了使用实时的monitor rest api获取信息,我们还可以开启部分logger的debug/trace模式来收集更多信息。

curl -XGET 'localhost:9600/_node/logging?pretty'可以看到当前logstash的所有logger的level。

然后我们可以通过以下方式临时调整logger level:

curl -XPUT 'localhost:9600/_node/logging?pretty' -H 'Content-Type: application/json' -d'
{
    "logger.logstash.outputs.elasticsearch" : "DEBUG"
}
'

也可以在log4j2.properties文件中加上下面的配置,实现永久生效的配置:

logger.elasticsearchoutput.name = logstash.outputs.elasticsearch
logger.elasticsearchoutput.level = debug

再次调用curl -XGET 'localhost:9600/_node/logging?pretty'可以看到当前logstash的部分logger的level已经修改了。

 

 

 

 

 

 

 

 

 

 

 类似资料: