logstash monitor

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>是可選的,指定要返回的節點信息的類型。

可以通過逗號分隔組合以下任何類型來限制返回的信息:

type desc
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>是可選的,有以下取值:

type desc
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已經修改了。

 

 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章