{"id":21047,"date":"2017-01-18T12:45:41","date_gmt":"2017-01-18T11:45:41","guid":{"rendered":"https:\/\/www.inovex.de\/?p=2555"},"modified":"2026-03-17T08:58:09","modified_gmt":"2026-03-17T07:58:09","slug":"kubernetes-logging-with-fluentd-and-the-elastic-stack","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/","title":{"rendered":"Kubernetes Logging with Fluentd and the Elastic Stack"},"content":{"rendered":"<p><a href=\"https:\/\/www.inovex.de\/de\/leistungen\/cloud\/kubernetes\/\" target=\"_blank\" rel=\"noopener\">Kubernetes<\/a> and <a href=\"https:\/\/www.docker.com\/\" target=\"_blank\" rel=\"noopener\">Docker<\/a> are great tools to manage your microservices, but operators and developers need tools to debug those microservices if things go south. Log messages and application metrics are the usual tools in this cases. To centralize the access to log events, the <a href=\"https:\/\/www.elastic.co\/de\/\" target=\"_blank\" rel=\"noopener\">Elastic Stack<\/a> with Elasticsearch and Kibana is a well-known toolset. In this blog post I want to show you how to integrate the logging of Kubernetes with the Elastic Stack. To start off, I will give an introduction to the log mechanism of Kubernetes, then I&#8217;ll show you how to collect the resulting log events and ship them into the Elastic Stack. I also provide a GitHub repository with a working demo. Finally, I highlight some considerations for the production deployment.<!--more--><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_83 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#Logging-in-Kubernetes\" >Logging in Kubernetes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#Fluentd\" >Fluentd<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#Considerations-for-Production-Deployments\" >Considerations for Production Deployments<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#Read-on\" >Read on<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#Join-us\" >Join us!<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Logging-in-Kubernetes\"><\/span>Logging in Kubernetes<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Kubernetes recommends applications to log to the standard streams <span class=\"lang:default decode:true crayon-inline\">stdout<\/span> and <span class=\"lang:default decode:true crayon-inline \">stderr<\/span>. Logging to these streams has\u00a0many advantages: First of all, both\u00a0streams have been\u00a0part of Unix systems for many decades. Thus the standard library of every major programming language does have support for logging to these streams. Nevertheless it is advisable to use a mature logging framework to manage the log verbosity and the log format. Secondly, logging to <span class=\"lang:default decode:true crayon-inline\">stdout<\/span> and <span class=\"lang:default decode:true crayon-inline \">stderr<\/span> does not involve any network protocol like syslog. Network logging protocols like syslog or <a href=\"http:\/\/docs.graylog.org\/en\/2.1\/pages\/gelf.html\" target=\"_blank\" rel=\"noopener\">GELF<\/a>\u00a0solve the problem of shipping the log messages to a central log destination. However, they come at a\u00a0cost. Developers need to implement those protocols and handle errors in the network. Finally, the two streams are endless by nature. Thus they are a natural fit for an endless stream of log messages. Therefore many modern manifestos for good application design like the <a href=\"https:\/\/12factor.net\/logs\" target=\"_blank\" rel=\"noopener\">twelve factor app<\/a> manifesto are recommending logging to <span class=\"lang:default decode:true crayon-inline\">stdout<\/span>.<\/p>\n<p>Kubernetes logs the content of the <span class=\"lang:default decode:true crayon-inline\">stdout<\/span> and <span class=\"lang:default decode:true crayon-inline \">stderr<\/span> streams of a pod to a file. It\u00a0creates one file for each container in a pod. The default location for these files is <span class=\"lang:default decode:true crayon-inline \">\/var\/log\/containers<\/span> . The filename contains the pod name, the namespace of the pod, the container name, and the container id. The file contains one JSON object per line of the two streams <span class=\"lang:default decode:true crayon-inline\">stdout<\/span> and <span class=\"lang:default decode:true crayon-inline\">stderr<\/span>. Kubernetes exposes the content of the log file to clients via its API. The following example shows the content of the file for a Kubernetes dashboard pod and the output of the <span class=\"lang:sh decode:true crayon-inline \">kubectl logs<\/span> command.<\/p>\n<pre class=\"lang:default decode:true \">$ cat \/var\/log\/containers\/kubernetes-dashboard-udemm_kube-system_kubernetes-dashboard-5e4b95ee53705d1b664ad64540e9ad072bd8c8908373ad26c0679e178587a82b.log\r\n\r\n{\"log\":\"Using HTTP port: 9090\\n\",\"stream\":\"stdout\",\"time\":\"2016-12-22T08:24:51.228867198Z\"}\r\n\r\n{\"log\":\"Creating API server client for \\n\",\"stream\":\"stdout\",\"time\":\"2016-12-22T08:24:51.232891038Z\"}\r\n\r\n{\"log\":\"Successful initial request to the apiserver, version: v1.5.1\\n\",\"stream\":\"stdout\",\"time\":\"2016-12-22T08:24:51.456582591Z\"}\r\n\r\n{\"log\":\"Creating in-cluster Heapster client\\n\",\"stream\":\"stdout\",\"time\":\"2016-12-22T08:24:51.456681353Z\"}\r\n\r\n$ kubectl logs --namespace=kube-system kubernetes-dashboard-udemm\r\n\r\nUsing HTTP port: 9090\r\n\r\nCreating API server client for \r\n\r\nSuccessful initial request to the apiserver, version: v1.5.1\r\n\r\nCreating in-cluster Heapster client\r\n\r\n<\/pre>\n<p>Hence, logging to <span class=\"lang:default decode:true crayon-inline\">stdout<\/span> and the <span class=\"lang:sh decode:true crayon-inline \">kubectl logs<\/span> command are a powerful combination to troubleshoot problems of applications running inside a pod. However, Kubernetes deletes all log files of a pod when it gets deleted, so\u00a0you\u00a0can&#8217;t troubleshoot errors in already deleted pods. To solve this problem I used <a href=\"http:\/\/www.fluentd.org\/\" target=\"_blank\" rel=\"noopener\">fluentd<\/a> together with the Elastic Stack to store and view the logs via a central tool.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fluentd\"><\/span>Fluentd<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Fluentd is a flexible log data collector. It supports various\u00a0inputs like log files or syslog and supports many outputs like elasticsearch or Hadoop. Fluentd converts each log line to an event. Those events can be processed and enriched in the fluentd pipeline. I have chosen fluentd since there is a good Kubernetes metadata plugin. This plugin parses the filename of the log file and uses this information to fetch additional metadata from the kubernetes API. The metadata like labels and annotations are attached to the log event as additional fields\u00a0so you can search and filter by this\u00a0information. Furthermore, we use the metadata to route the log events to the proper elasticsearch indices. I use one index per pod, so I can implement a log rotation policy for each kind of pod. E.g. you\u00a0may want to store the logs of a back-end system for two weeks but the access logs of the front-end for\u00a0two days only.<\/p>\n<p>To deploy fluentd into the Kubernetes cluster I have chosen a DaemonSet. A DaemonSet ensures that a certain pod is scheduled to each kubelet exactly once. The fluentd pod mounts the <span class=\"lang:default decode:true crayon-inline\">\/var\/lib\/containers\/<\/span>\u00a0host volume to access the logs of all pods scheduled to that kubelet\u00a0as well as a host volume for a fluentd position file. This position file saves which log lines are already shipped to the central log store. The fluentd setup described here can be created with the following yaml file. It\u00a0contains the configuration of the DaemonSet and a ConfigMap. The configmap holds the fluentd configuration:<\/p>\n<pre class=\"height-set:true lang:yaml decode:true\"># This config should be kept as similar as possible to the one at\r\n\r\n# cluster\/addons\/gci\/fluentd-gcp.yaml\r\n\r\napiVersion: extensions\/v1beta1\r\n\r\nkind: DaemonSet\r\n\r\nmetadata:\r\n\r\n  name: fluentd-logging\r\n\r\n  namespace: kube-system\r\n\r\n  labels:\r\n\r\n    k8s-app: fluentd-logging\r\n\r\n    version: v1\r\n\r\n    #kubernetes.io\/cluster-service: \"true\"\r\n\r\nspec:\r\n\r\n  template:\r\n\r\n    metadata:\r\n\r\n      name: fluentd-logging\r\n\r\n      # If you want different namespace replace it.\r\n\r\n      namespace: kube-system\r\n\r\n      labels:\r\n\r\n        k8s-app: fluentd-logging\r\n\r\n    spec:\r\n\r\n      dnsPolicy: Default\r\n\r\n      containers:\r\n\r\n      - name: fluentd-logging\r\n\r\n        # For Production use replace image name by an image in your private registry and set imagePullPolicy to reasonable value.\r\n\r\n        image: local\/kubernetes-logging:1.19\r\n\r\n        imagePullPolicy: Never\r\n\r\n        volumeMounts:\r\n\r\n        # Mount log directory of the host readonly to access all log files.\r\n\r\n        - name: varlog\r\n\r\n          mountPath: \/var\/log\/\r\n\r\n          readOnly: true\r\n\r\n        - name: varlibdockercontainers\r\n\r\n          mountPath: \/var\/log\/containers\r\n\r\n          readOnly: true\r\n\r\n        # Path where the position file is stored.\r\n\r\n        - name: fluentdposfiles\r\n\r\n          mountPath: \/var\/lib\/fluentd\r\n\r\n        # This mount is minikube specific since \/var\/log\/containers\/*.log are symlinks into this mount.\r\n\r\n        # Probably you will not need it in produktion. Maybe you have to replace it by a mount of \/var\/lib\/docker\/containers since normal kubernetes\r\n\r\n        # symlinks into that directory.\r\n\r\n        - name: minikubemount\r\n\r\n          mountPath: \/mnt\/sda1\/var\/lib\/docker\/containers\r\n\r\n          readOnly: true\r\n\r\n        # Mount the configuration file.\r\n\r\n        - name: config-volume\r\n\r\n          mountPath: \/etc\/td-agent\r\n\r\n      terminationGracePeriodSeconds: 30\r\n\r\n      volumes:\r\n\r\n      - name: varlog\r\n\r\n        hostPath:\r\n\r\n          path: \/var\/log\/\r\n\r\n      - name: varlibdockercontainers\r\n\r\n        hostPath:\r\n\r\n          path: \/var\/log\/containers\r\n\r\n      # In production put this position file somewhere where it survives node restarts.\r\n\r\n      - name: fluentdposfiles\r\n\r\n        hostPath:\r\n\r\n          path: \/tmp\/fluentd\r\n\r\n      - name: minikubemount\r\n\r\n        hostPath:\r\n\r\n          path: \/mnt\/sda1\/var\/lib\/docker\/containers\r\n\r\n      - name: config-volume\r\n\r\n        configMap:\r\n\r\n          name: fluentd-config\r\n\r\n---\r\n\r\napiVersion: v1\r\n\r\ndata:\r\n\r\n  td-agent.conf: |-\r\n\r\n    # Do not directly collect fluentd's own logs to avoid infinite loops.\r\n\r\n    &lt;match fluent.**&gt;\r\n\r\n      type null\r\n\r\n    &lt;\/match&gt;\r\n\r\n    # Example:\r\n\r\n    # {\"log\":\"[info:2016-02-16T16:04:05.930-08:00] Some log text here\\n\",\"stream\":\"stdout\",\"time\":\"2016-02-17T00:04:05.931087621Z\"}\r\n\r\n    &lt;source&gt;\r\n\r\n      type tail\r\n\r\n      path \/var\/log\/containers\/*.log\r\n\r\n      pos_file \/var\/lib\/fluentd\/es-containers.log.pos\r\n\r\n      time_format %Y-%m-%dT%H:%M:%S.%NZ\r\n\r\n      tag kubernetes.*\r\n\r\n      format json\r\n\r\n      read_from_head true\r\n\r\n    &lt;\/source&gt;\r\n\r\n    # This plugin the metadata from the kubernetes API.\r\n\r\n    &lt;filter kubernetes.**&gt;\r\n\r\n      type kubernetes_metadata\r\n\r\n    &lt;\/filter&gt;\r\n\r\n    # This configures the elasticsearch output. It assumes the DNS name `elasticsearch-logging` as the target elasticsearch.\r\n\r\n    # The @type elasticsearch_dynamic allows to route the\r\n\r\n    &lt;match kubernetes.**&gt;\r\n\r\n      @type elasticsearch_dynamic\r\n\r\n      host elasticsearch-logging\r\n\r\n      port 9200\r\n\r\n      # Save the tag key\r\n\r\n      include_tag_key true\r\n\r\n      # Use the logstash format\r\n\r\n      logstash_format true\r\n\r\n      # Saves the log events to the index kubernetes-&lt;pod_name&gt;.\r\n\r\n      logstash_prefix kubernetes-${record['kubernetes']['pod_name']}\r\n\r\n      # Set the chunk limit the same as for fluentd-gcp.\r\n\r\n      buffer_chunk_limit 2M\r\n\r\n      # Cap buffer memory usage to 2MiB\/chunk * 32 chunks = 64 MiB\r\n\r\n      buffer_queue_limit 32\r\n\r\n      flush_interval 5s\r\n\r\n      # Never wait longer than 5 minutes between retries.\r\n\r\n      max_retry_wait 30\r\n\r\n      retry_wait 10s\r\n\r\n      # Disable the limit on the number of retries (retry forever).\r\n\r\n      disable_retry_limit\r\n\r\n      # Use multiple threads for processing.\r\n\r\n      num_threads 1\r\n\r\n    &lt;\/match&gt;\r\n\r\nkind: ConfigMap\r\n\r\nmetadata:\r\n\r\n  creationTimestamp: null\r\n\r\n  name: fluentd-config\r\n\r\n  namespace: kube-system\r\n\r\n<\/pre>\n<p>The complete demonstration based on minikube can be found <a href=\"https:\/\/github.com\/inovex\/kubernetes-logging\" target=\"_blank\" rel=\"noopener\">in this GitHub Repository<\/a>.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Considerations-for-Production-Deployments\"><\/span>Considerations for Production Deployments<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>In a production environment you\u00a0have to implement a log rotation of the stored log data. Since the above fluentd configuration generates one index per day this is easy. <a href=\"https:\/\/github.com\/elastic\/curator\" target=\"_blank\" rel=\"noopener\">Elasticsearch Curator<\/a> is a tool made for exactly this job. The minikube demonstration provides\u00a0a good starting point to setup Curator in a Kubernetes environment.<\/p>\n<p>As discussed above logging to <span class=\"lang:default decode:true crayon-inline \">stdout<\/span>\u00a0is very easy. However, you&#8217;ll\u00a0want to log the data in a structured fashion\u00a0to allow more efficient search in the log data. The demo linked above contains two minimal example applications, <span class=\"lang:default decode:true crayon-inline \">normal_logging<\/span>\u00a0and <span class=\"lang:default decode:true crayon-inline\">structured_logging<\/span>. The following snippet shows that their log outputs contain the same amount of information.<\/p>\n<pre class=\"lang:default decode:true \">$ kubectl logs normal-logging-2250448850-24m73 | tail -n 1\r\n\r\n Textlen=609 prefix=2 words=100 level=info msg=\"In previous blog articles we talked about the new master. The additional slaves will be reconfigured automatically to use the new master. The application\/clients that are using the Redis setup will be informed about the new address to use the new address. Configuration and example setup with three nodes The Sentinel process is a good start, so run your Redis Master and two Slaves before setting up the Sentinel which Redis master it should monitor. In short, these are the benefits of using Sentinel: Monitoring: Sentinel constantly checks if the Redis setup will be informed about the basic Redis features\" time=\"2016-12-23T09:08:09Z\"\r\n\r\n$ kubectl logs structured-logging-4189333180-10lsn | tail -n 1\r\n\r\n{\"Textlen\":599,\"words\":100,\"prefix\":2,\"level\":\"info\",\"msg\":\"In previous blog articles we talked about the basic Redis features and learned how to persist, backup and restore your dataset in cause of a distributed system. That means your Sentinel processes are a part of a distributed system. That means clients can connect to the Sentinel processes. On each of your Redis Master and two Slaves before setting up the Sentinel which Redis master it should monitor. In short, these are the benefits of using Sentinel: Monitoring: Sentinel constantly checks if the Redis setup will be informed about the basic Redis features and learned how to persist, backup and\",\"time\":\"2016-12-23T09:08:35Z\"}<\/pre>\n<p>The normal logging application prints the log message in a custom log format resembling\u00a0a key=value format. The structured logging application logs the same amount of information as JSON, one complete JSON event per log message. Fluentd will recognize that JSON event per line and use it\u00a0as a base for the stored log event in the Elasticsearch index so it can use those keys as fields in the Kibana front-end. The following screenshot\u00a0shows a log message of the structured logger in the Kibana front-end. No\u00a0additional parsing was configured in the fluentd pipeline.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2016\/12\/structured_logging.png\" alt=\"Structured log message in the kibana frontend\" \/><\/p>\n<p>The same effect can be achieved by parsing the log messages of the normal logging application in the fluentd pipeline, but not without a cost:\u00a0Somebody has to maintain the parsing code, which usually\u00a0is a set of regular expressions. Since each application tends to have its own log format, the set of regular expressions will grow. Furthermore fluentd has\u00a0to invest CPU time to execute the parsing.<\/p>\n<p>My personal preference is to establish the following policy: Logs to <span class=\"lang:default decode:true crayon-inline \">stdout<\/span>\u00a0have to be in JSON format. The disadvantage of that policy is that JSON is not that human readable and developers read logs a lot during development. A mature log handling library allowing different configurable log formats might help the developer to implement this policy, so they\u00a0can chose a more readable log format while developing a new feature.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Read-on\"><\/span>Read on<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Have a look at our website to find out more about the services we offer in <a href=\"https:\/\/www.inovex.de\/en\/our-services\/it-engineering\/\">IT Engineering<\/a> and\u00a0<a href=\"https:\/\/www.inovex.de\/de\/leistungen\/cloud\/kubernetes\/\">Kubernetes<\/a> (in German)\u00a0write an email to <a href=\"mailto:info@inovex.de\" target=\"_blank\" rel=\"noopener\">info@inovex.de<\/a> for more information or call <a href=\"tel:+497216190210\">+49 721 619 021-0<\/a>.<\/p>\n<div style=\"margin: 7px; padding: 7px; border-left: 6px solid #9CCD00;\">\n<h2><span class=\"ez-toc-section\" id=\"Join-us\"><\/span>Join us!<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Looking for a job where you can work with cutting edge technology on a daily basis? We&#8217;re currently hiring Linux Systems Engineers (m\/w\/d) in Karlsruhe, Pforzheim, Munich, Cologne and Hamburg!<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Kubernetes and Docker are great tools to manage your microservices, but operators and developers need tools to debug those microservices if things go south. Log messages and application metrics are the usual tools in this cases. To centralize the access to log events, the Elastic Stack with Elasticsearch and Kibana is a well-known toolset. In [&hellip;]<\/p>\n","protected":false},"author":33,"featured_media":12909,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[79],"service":[423],"coauthors":[{"id":33,"display_name":"Christoph Petrausch","user_nicename":"cpetrausch"}],"class_list":["post-21047","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-replatforming","service-kubernetes"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.6 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Kubernetes and Docker are great tools to manage your microservices, but operators and developers need tools to debug those microservices if things go south. Log messages and application metrics are the usual tools in this cases. To centralize the access to log events, the Elastic Stack with Elasticsearch and Kibana is a well-known toolset. In [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2017-01-18T11:45:41+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-03-17T07:58:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png\" \/>\n\t<meta property=\"og:image:width\" content=\"2300\" \/>\n\t<meta property=\"og:image:height\" content=\"678\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Christoph Petrausch\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd-1024x302.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Christoph Petrausch\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"10\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Christoph Petrausch\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/\"},\"author\":{\"name\":\"Christoph Petrausch\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/50e956dd05d9f8e78fd21af3c4d43aa4\"},\"headline\":\"Kubernetes Logging with Fluentd and the Elastic Stack\",\"datePublished\":\"2017-01-18T11:45:41+00:00\",\"dateModified\":\"2026-03-17T07:58:09+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/\"},\"wordCount\":1169,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2017\\\/01\\\/kubernetes-elastic-fluentd.png\",\"keywords\":[\"Replatforming\"],\"articleSection\":[\"English Content\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/\",\"name\":\"Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2017\\\/01\\\/kubernetes-elastic-fluentd.png\",\"datePublished\":\"2017-01-18T11:45:41+00:00\",\"dateModified\":\"2026-03-17T07:58:09+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2017\\\/01\\\/kubernetes-elastic-fluentd.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2017\\\/01\\\/kubernetes-elastic-fluentd.png\",\"width\":2300,\"height\":678,\"caption\":\"Logos Kubernetes Elastic Fluentd\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-logging-with-fluentd-and-the-elastic-stack\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Kubernetes Logging with Fluentd and the Elastic Stack\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/50e956dd05d9f8e78fd21af3c4d43aa4\",\"name\":\"Christoph Petrausch\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/ChristophGopher-96x96.jpgcf9e8d784b562ae315f87ec9665b820b\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/ChristophGopher-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/ChristophGopher-96x96.jpg\",\"caption\":\"Christoph Petrausch\"},\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/cpetrausch\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/","og_locale":"de_DE","og_type":"article","og_title":"Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH","og_description":"Kubernetes and Docker are great tools to manage your microservices, but operators and developers need tools to debug those microservices if things go south. Log messages and application metrics are the usual tools in this cases. To centralize the access to log events, the Elastic Stack with Elasticsearch and Kibana is a well-known toolset. In [&hellip;]","og_url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2017-01-18T11:45:41+00:00","article_modified_time":"2026-03-17T07:58:09+00:00","og_image":[{"width":2300,"height":678,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png","type":"image\/png"}],"author":"Christoph Petrausch","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd-1024x302.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Christoph Petrausch","Gesch\u00e4tzte Lesezeit":"10\u00a0Minuten","Written by":"Christoph Petrausch"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/"},"author":{"name":"Christoph Petrausch","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/50e956dd05d9f8e78fd21af3c4d43aa4"},"headline":"Kubernetes Logging with Fluentd and the Elastic Stack","datePublished":"2017-01-18T11:45:41+00:00","dateModified":"2026-03-17T07:58:09+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/"},"wordCount":1169,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png","keywords":["Replatforming"],"articleSection":["English Content","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/","url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/","name":"Kubernetes Logging with Fluentd and the Elastic Stack - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png","datePublished":"2017-01-18T11:45:41+00:00","dateModified":"2026-03-17T07:58:09+00:00","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2017\/01\/kubernetes-elastic-fluentd.png","width":2300,"height":678,"caption":"Logos Kubernetes Elastic Fluentd"},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-logging-with-fluentd-and-the-elastic-stack\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Kubernetes Logging with Fluentd and the Elastic Stack"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/50e956dd05d9f8e78fd21af3c4d43aa4","name":"Christoph Petrausch","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/wp-content\/uploads\/ChristophGopher-96x96.jpgcf9e8d784b562ae315f87ec9665b820b","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/ChristophGopher-96x96.jpg","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/ChristophGopher-96x96.jpg","caption":"Christoph Petrausch"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/cpetrausch\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21047","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=21047"}],"version-history":[{"count":3,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21047\/revisions"}],"predecessor-version":[{"id":66597,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/21047\/revisions\/66597"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/12909"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=21047"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=21047"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=21047"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=21047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}