cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: service-hierarchy-configuration.md

SkyWalking v10 introduces a new concept `Service Hierarchy` which defines the relationships of existing logically same services in various layers. The concept and design could be found . All the relationships defined in the `config/hierarchy-definition.yml` file. You can customize it according to your own needs. Here is an example: ```yaml hierarchy: MESH: MESH_DP: name K8S_SERVICE: short-name MESH_DP: K8S_SERVICE: short-name GENERAL: K8S_SERVICE: lower-short-name-remove-ns MYSQL: K8S_SERVICE: short-name POSTGRESQL: K8S_SERVICE: short-name SO11Y_OAP: K8S_SERVICE: short-name VIRTUAL_DATABASE: MYSQL: lower-short-name-with-fqdn POSTGRESQL: lower-short-name-with-fqdn auto-matching-rules: name: "{ (u, l) -> u.name == l.name }" short-name: "{ (u, l) -> u.shortName == l.shortName }" lower-short-name-remove-ns: "{ (u, l) -> { if(l.shortName.lastIndexOf('.') > 0) return u.shortName == l.shortName.substring(0, l.shortName.lastIndexOf('.')); return false; } }" lower-short-name-with-fqdn: "{ (u, l) -> { if(u.shortName.lastIndexOf(':') > 0) return u.shortName.substring(0, u.shortName.lastIndexOf(':')) == l.shortName.concat('.svc.cluster.local'); return false; } }" layer-levels: MESH: 3 GENERAL: 3 SO11Y_OAP: 3 VIRTUAL_DATABASE: 3 MYSQL: 2 POSTGRESQL: 2 MESH_DP: 1 K8S_SERVICE: 0 ``` The hierarchy of service layers are defined in the `hierarchy` section. The layers under the specific layer are related lower of the layer. The relation could have a matching rule for auto matching, which are defined in the `auto-matching-rules` section. The relation without a matching rule should be built through the internal API. All the layers are defined in the file `org.apache.skywalking.oap.server.core.analysis.Layers.java`. If the hierarchy is not defined, the service hierarchy relationship will not be built. If you want to add a new relationship, you should certainly know they can be matched automatically by . Notice: some hierarchy relations and auto matching rules are only works on k8s env. The auto matching rules are defined in the `auto-matching-rules` section. Use Groovy script to define the matching rules, the input parameters are the upper service(u) and the lower service(l) and the return value is a boolean, which are used to match the relation between the upper service(u) and the lower service(l) on the different layers. The default matching rules required the service name configured as SkyWalking default and follow the . If you customized the service name in any layer, you should customize the related matching rules according your service name rules. Define the hierarchy level of the service layer in the `layer-levels` section. The level is used to define the order of the service layer for UI presentation. The level of the upper service should greater than the level of the lower service in `hierarchy` section.
Project: Checkmk (Observability and Analysis / Observability)
File: 16617.md

key | value | date | 2024-03-15T15:28:00+00:00 version | 2.4.0b1 class | feature edition | cre component | wato level | 1 compatible | yes When a user edits a configuration e.g. for a special agent with an explicit password the complete configuration is transfered to the user. To not reveal the password in cleartext this field is encrypted. The key for that encryption was previously to this Werk shared amongst all users (a salt was used though). With this Werk every user session has now a secret dedicated to this encryption so the key is rotated often and not shared amongst other users.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: vmnodescrape.md

sort: 7 weight: 7 title: VMNodeScrape menu: docs: parent: "operator-custom-resources" weight: 7 aliases: /operator/resources/vmnodescrape.html The `VMNodeScrape` CRD provides discovery mechanism for scraping metrics kubernetes nodes, it is useful for node exporters monitoring. `VMNodeScrape` object generates part of configuration. It has various options for scraping configuration of target (with basic auth,tls access, by specific port name etc.). By specifying configuration at CRD, operator generates config for and syncs it. It's useful for cadvisor scraping, node-exporter or other node-based exporters. `VMAgent` `nodeScrapeSelector` must match `VMNodeScrape` labels. More information about selectors you can find in . You can see the full actual specification of the `VMNodeScrape` resource in the . Also, you can check out the section. ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMNodeScrape metadata: name: cadvisor-metrics spec: scheme: "https" tlsConfig: insecureSkipVerify: true caFile: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" bearerTokenFile: "/var/run/secrets/kubernetes.io/serviceaccount/token" relabelConfigs: action: labelmap regex: metakubernetesnodelabel(.+) targetLabel: address replacement: kubernetes.default.svc:443 sourceLabels: [metakubernetesnode_name] regex: (.+) targetLabel: metrics_path replacement: /api/v1/nodes/$1/proxy/metrics/cadvisor ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16646.md

key | value | date | 2024-03-18T20:52:03+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This fixes a regression introduced in Checkmk 2.3.0b1 for Nagios / CRE users. The reported error during config creation was "Error precompiling checks for host \<HOST\>: Cannot find check file needed for \<agent_name\>".
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_configMap.KubeConfigMap.md

title: "Interface: KubeConfigMap" linkTitle: "KubeConfigMap" slug: "libk8sconfigMap.KubeConfigMap" .KubeConfigMap `KubeConfigMap` `Optional` apiVersion: `string` . _ data: _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: .
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_10s_pleg_relist_latency_quantile_09.md

This alert indicates that the average relisting latency of the Pod Lifecycle Event Generator (PLEG) in Kubelet over the last 10 seconds compared to the last minute (quantile 0.9) has increased significantly. This can cause the node to become unavailable (NotReady) due to a "PLEG is not healthy" event. Check for high node resource usage First, ensure that the node does not have an overly high number of Pods. High resource usage could increase the PLEG relist latency, leading to poor Kubelet performance. You can check the current number of running Pods on a node using the following command: ``` kubectl get pods --all-namespaces -o wide | grep <node-name> ``` Check Kubelet logs for errors Inspect the Kubelet logs for any errors that might be causing the increased PLEG relist latency. You can check the Kubelet logs using the following command: ``` sudo journalctl -u kubelet ``` Look for any errors associated with PLEG or the container runtime, such as Docker or containerd. Check container runtime health If you find any issues in the Kubelet logs related to the container runtime, investigate the health of the container runtime, such as Docker or containerd, and its logs to identify any issues: For Docker, you can check its health using: ``` sudo docker info sudo journalctl -u docker ``` For containerd, you can check its health using: ``` sudo ctr version sudo journalctl -u containerd ``` Adjust the maximum number of Pods per node If you have configured your cluster manually (e.g., with `kubeadm`), you can update the value of max Pods in the Kubelet configuration file. The default file location is `/var/lib/kubelet/config.yaml`. Change the `maxPods` value according to your requirements and restart the Kubelet service: ``` sudo systemctl restart kubelet ``` Monitor the PLEG relist latency After making any necessary changes, continue monitoring the PLEG relist latency to ensure the issue has been resolved.
Project: Checkmk (Observability and Analysis / Observability)
File: 16497.md

key | value | date | 2024-03-07T09:45:40+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, if configured, proxy was used to connect to all clients except for the 'STS' client. This led to a crash in the agent if 'STS' client was only accessible via proxy. Now, the configured proxy will be used for the 'STS' client as well.
Project: Checkmk (Observability and Analysis / Observability)
File: 16805.md

key | value | date | 2024-04-23T11:57:59+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The `mkp package <manifest>` command would fail with "File conflict: /omd/sites/mydevsite/local/... (already existing)" if called in a site context. Additionally, we no longer write the mkp-tools version into the "version.min_required" field of the manifest template.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: traceloop.md

title: Gadget traceloop The traceloop gadget traces system calls in a similar way to strace but with some differences: traceloop uses eBPF instead of ptrace traceloop&#39;s tracing granularity is the container instead of a process traceloop&#39;s traces are recorded in a fast, in-memory, overwritable ring buffer like a flight recorder. The tracing could be permanently enabled and inspected in case of crash. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: traceloop namespace: gadget spec: node: ubuntu-hirsute gadget: traceloop runMode: Manual outputMode: ExternalResource ``` Collect traceloop ```bash $ kubectl annotate -n gadget trace/traceloop \ gadget.kinvolk.io/operation=collect ``` Delete a perf ring buffer owned by traceloop ```bash $ kubectl annotate -n gadget trace/traceloop \ gadget.kinvolk.io/operation=delete ``` Start traceloop ```bash $ kubectl annotate -n gadget trace/traceloop \ gadget.kinvolk.io/operation=start ``` Stop traceloop ```bash $ kubectl annotate -n gadget trace/traceloop \ gadget.kinvolk.io/operation=stop ``` Status Stream
Project: Infracost (Observability and Analysis / Continuous Optimization)
File: CHANGELOG.tpl.md

All notable changes to this project will be documented in this file. {{ if .Versions -}} <a name="unreleased"></a> {{ if .Unreleased.CommitGroups -}} {{ range .Unreleased.CommitGroups -}} {{ range .Commits -}} {{/ SKIPPING RULES - START / -}} {{- if not (hasPrefix .Subject "Updated CHANGELOG") -}} {{- if not (contains .Subject "[ci skip]") -}} {{- if not (contains .Subject "[skip ci]") -}} {{- if not (hasPrefix .Subject "Merge pull request ") -}} {{- if not (hasPrefix .Subject "Added CHANGELOG") -}} {{- / SKIPPING RULES - END / -}} {{ if .Scope }}{{ .Scope }}: {{ end }}{{ .Subject }} {{/ SKIPPING RULES - START / -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{/ SKIPPING RULES - END / -}} {{ end }} {{ end -}} {{ else }} {{ range .Unreleased.Commits -}} {{/ SKIPPING RULES - START / -}} {{- if not (hasPrefix .Subject "Updated CHANGELOG") -}} {{- if not (contains .Subject "[ci skip]") -}} {{- if not (contains .Subject "[skip ci]") -}} {{- if not (hasPrefix .Subject "Merge pull request ") -}} {{- if not (hasPrefix .Subject "Added CHANGELOG") -}} {{- / SKIPPING RULES - END / -}} {{ if .Scope }}{{ .Scope }}: {{ end }}{{ .Subject }} {{/ SKIPPING RULES - START / -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{/ SKIPPING RULES - END / -}} {{ end }} {{ end -}} {{ end -}} {{ range .Versions }} <a name="{{ .Tag.Name }}"></a> {{ if .CommitGroups -}} {{ range .CommitGroups -}} {{ range .Commits -}} {{/ SKIPPING RULES - START / -}} {{- if not (hasPrefix .Subject "Updated CHANGELOG") -}} {{- if not (contains .Subject "[ci skip]") -}} {{- if not (contains .Subject "[skip ci]") -}} {{- if not (hasPrefix .Subject "Merge pull request ") -}} {{- if not (hasPrefix .Subject "Added CHANGELOG") -}} {{- / SKIPPING RULES - END / -}} {{ if .Scope }}{{ .Scope }}: {{ end }}{{ .Subject }} {{/ SKIPPING RULES - START / -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{/ SKIPPING RULES - END / -}} {{ end }} {{ end -}} {{ else }} {{ range .Commits -}} {{/ SKIPPING RULES - START / -}} {{- if not (hasPrefix .Subject "Updated CHANGELOG") -}} {{- if not (contains .Subject "[ci skip]") -}} {{- if not (contains .Subject "[skip ci]") -}} {{- if not (hasPrefix .Subject "Merge pull request ") -}} {{- if not (hasPrefix .Subject "Added CHANGELOG") -}} {{- / SKIPPING RULES - END / -}} {{ if .Scope }}{{ .Scope }}: {{ end }}{{ .Subject }} {{/ SKIPPING RULES - START / -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}} {{/ SKIPPING RULES - END / -}} {{ end }} {{ end -}} {{- if .NoteGroups -}} {{ range .NoteGroups -}} {{ range .Notes }} {{ .Body }} {{ end }} {{ end -}} {{ end -}} {{ end -}} {{- if .Versions }} {{ range .Versions -}} {{ if .Tag.Previous -}} {{ end -}} {{ end -}} {{ end -}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16401.md

key | value | date | 2024-02-02T12:32:48+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes The command `omd start mkeventd` starts the event daemon. Previously, any exit code produced by this daemon would be ignored. Now, if the exit code is non-zero, then the message `Failed` is shown and the command `omd start mkeventd` exits with error code 2.
Project: Checkmk (Observability and Analysis / Observability)
File: 16790.md

key | value | date | 2024-04-19T11:48:42+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When creating an `AgentConfig` rulespec using the Ruleset API an error ``` KeyError: 'cmk-match-type' ``` was raised.
Project: Vector (Observability and Analysis / Observability)
File: 2021-02-16-vector-remap-language.md

date: "2021-02-16" title: "Introducing Vector Remap Language" description: "A lean, fast, and safe language for transforming observability data." authors: ["binarylogic"] featured: true pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "featured" domains: ["remap"] The Vector team is excited to announce the Vector Remap Language (VRL) is an expression-oriented language designed to work with observability data (logs and metrics) in a safe and performant manner. It features a , a rich set of tailored to observability use cases, and that set it far apart from other options. This 0.12 release of Vector marks the official release of the language. Read the announcement post: {{< jump "/blog/vector-remap-language" >}} If your interest in VRL is now piqued, we recommend checking out these resources: The on the Vector blog The VRL
Project: Icinga (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' A clear and concise description of what the problem is. Ex. I'm always using this feature but am missing [...] A clear and concise description of what you want to happen. A clear and concise description of any alternative solutions or features you've considered. Add any other context or screenshots about the feature request here.
Project: Grafana (Observability and Analysis / Observability)
File: example.md

labels: products: enterprise oss title: Shared Content Use test.md to experiment and test formats and syntax. When you have a chunk of text or steps that stand alone, not part of an ordered or unordered list. This includes headings, paragraphs, full lists, and combinations of those content types. The syntax to invoke this file would be the following, minus the backslash: ``` \{{< docs/shared lookup="example.md" source="grafana" version="<GRAFANA VERSION>" >}} ``` When you have steps that you want to use in more than one numbered list. This format does not work as well for unordered lists, but it does work. Below is an example from the docs, with backslashes added. The initial spaces are not necessary for the numbered list to work and make no difference in the output, but they aid in code readability. ``` \{{< docs/list >}} \{{< docs/shared lookup="manage-users/view-server-user-list.md" source="grafana" version="<GRAFANA VERSION>" >}} Click the user account that you want to edit. If necessary, use the search field to find the account. \{{< /docs/list >}} ``` You cannot use short codes in an ordered list with sublists. The shortcode breaks the sublist indentation. All unordered list steps included as part of a list will appear as second-level lists (with the hollow circle bullet) rather than first-level lists (solid circle bullet), even if the list is not indented in the shared file or the document file. {{< docs/list >}} {{< docs/shared lookup="test.md" source="grafana" version="<GRAFANA VERSION>" >}} Bullet text {{< /docs/list >}}
Project: Grafana Tempo (Observability and Analysis / Observability)
File: prettier_rules.md

This files contains rules for prettifying PromQL expressions. Note: The current version of prettier does not preserve comments. `maxcharactersper_line`: Maximum number of characters that will be allowed on a single line in a prettified PromQL expression. A node exceeding the `maxcharactersper_line` will qualify for split unless It is a `MatrixSelector` It is a `VectorSelector`. Label sets in a `VectorSelector` will be in the same line as metric_name, separated by commas and a space Note: Label groupings like `by`, `without`, `on`, `ignoring` will remain on the same line as their parent node Nodes that are nested within another node will be prettified only if they exceed the `maxcharactersper_line` Expressions like `sum(expression) without (labelmatchers)` will be modified to `sum without(labelmatchers) (expression)` Functional call args will be split to different lines if they exceed the `maxcharactersper_line`
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_get.md

category: DashboardGraph apiurl: '/api/v1/dashboard/graph/:id' title: 'Get DashboardGraph info by id' type: 'GET' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ``` { "counters":["value/name=pfc.push.ms", "value/name=pfc.push.size"], "endpoints":["laiweiofficemac"], "falcon_tags":"", "graph_id":4626, "graph_type":"h", "method":"", "position":4626, "screen_id":953, "timespan":3600, "title":"test" }``` For errors responses, see the .
Project: Graylog (Observability and Analysis / Observability)
File: ux-patterns.md

Rely on the shared components `FormSubmit` and `ModalSubmit` to implement the submit and cancel button. The `FormSubmit` can be used for all forms on pages. The `ModalSubmit` can be used for modals and similar element like popovers or the login dialog. Make sure to follow the placements defined by these shared components. Currently: submit buttons in form are vertically aligned with the inputs. The cancel button is being placed after the submit button. submit buttons in modals are always placed in the right bottom corner. The cancel button is being placed before the submit button. When defining a name for the submit button Instead of `Save` or `Ok` use a meaningful name for the submit button like `Create stream`. Make sure to write only the first letter uppercase and all other letter lowercase. Always use `Cancel` for the cancel button name. These three components are closely related and maybe confusing to decide which one to use for which situation. `EmptyEntity` should be used to display a message for an entity that does not have any entries in the database yet. This components supports displaying a message explaining what the entity is and can also support including a button link to create one via the children props `NoEntitiesExist` is similar to `EmptyEntity` except it is a more generic message without including the option to create a new one `NoSearchResults` should be used in the case when a search is performed with a query and the result is no matching entries. This component should inform the user that entities still exist, just that none match the current filter.
Project: Checkmk (Observability and Analysis / Observability)
File: 16450.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-15T08:47:52+00:00 level | 1 class | fix component | ec edition | cre With werk 16012 the active configuration folder was introduced. During an update the event console configuration is synchronized to this folder which is missing for the raw edition. Fixed that.
Project: Checkmk (Observability and Analysis / Observability)
File: 16681.md

key | value | date | 2024-04-17T10:07:49+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no The active check "http" allows different configurations for the address family in the host settings, among others the primary address family. If this option is selected, a primary IP address now has to be configured for the relevant host. An IP address also has to be configured for the host if no explicit address is configured in the rule. Note that this active check is being deprecated in favor of the newer "httpv2".
Project: SkyWalking (Observability and Analysis / Observability)
File: v3-version-upgrade.md

There is no information showing in the UI. In the upgrade from version 3.2.6 to 5.0.0, the existing Elasticsearch indexes are kept, but aren't compatible with 5.0.0-alpha. When service name is registered, ElasticSearch will create this column by default type string, which will lead to an error. Clean the data folder in ElasticSearch and restart ElasticSearch, collector and your application under monitoring.
Project: Grafana Loki (Observability and Analysis / Observability)
File: cri.md

title: cri menuTitle: description: The 'cri' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/cri/ weight: The `cri` stage is a parsing stage that reads the log line using the standard CRI logging format. ```yaml cri: [maxpartiallines: <int> | default = 100] [maxpartialline_size: <int> | default = 0] [maxpartiallinesizetruncate: <bool> | default = false] ``` Unlike most stages, the `cri` stage provides no configuration options and only supports the specific CRI log format. CRI specifies log lines as space-delimited values with the following components: `time`: The timestamp string of the log `stream`: Either stdout or stderr `flags`: CRI flags including F or P `log`: The contents of the log line No whitespace is permitted between the components. In the following example, only the first log line can be properly formatted using the `cri` stage: ``` "2019-01-01T01:00:00.000000001Z stderr P test\ngood" "2019-01-01 T01:00:00.000000001Z stderr testgood" "2019-01-01T01:00:00.000000001Z testgood" ``` For the given pipeline: ```yaml cri: {} ``` Given the following log line: ``` "2019-04-30T02:12:41.8443515Z stdout F message" ``` The following key-value pairs would be created in the set of extracted data: `content`: `message` `stream`: `stdout` `flags`: `xx` `timestamp`: `2019-04-30T02:12:41.8443515` - The cri-stage both extracts the timestamp as a label and set it as the timestamp of the log entry.