cwielenb/CNCF-Dataset huggingface dataset:
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: deploy_relay_proxy.md

sidebar_position: 70 description: Deploy the relay proxy. The relay proxy can be deployed in Kubernetes using a helm chart. Helm is an invaluable tool for configuring and deploying applications to a Kubernetes environment. Below are the steps for installing a Helm Chart from a GO Feature Flag Helm repository. Access to a Kubernetes cluster Helm CLI installed on the client machine Add the repository to Helm with the Helm repository add command and provide a name and the repository URL. For example: ```shell helm repo add go-feature-flag https://charts.gofeatureflag.org/ ``` Install the Helm Chart with the Helm install command and provide the custom repository name, the chart name and any necessary values files. You can look at the to know exactly what you can change in the values.yaml file. ```shell helm install go-feature-flag/relay-proxy -f values.yaml ``` Verify the Helm Chart installation with the Helm list command. For example: ```shell helm list ``` The GO Feature Flag relay proxy can easily be launched as an AWS Lambda function. To do this, simply set the `startAsAwsLambda` option in your configuration file to `true`, like so: ```yaml startAsAwsLambda: true ``` Once you've updated your configuration file, you can deploy your function in AWS and configure it to be accessible via HTTP. This can be achieved by creating an API Gateway or an Application Load Balancer (ALB) and linking it to your Lambda function. By configuring your GO Feature Flag relay proxy to run as an AWS Lambda function, you can take advantage of the many benefits of serverless computing, including automatic scaling, reduced infrastructure costs, and simplified deployment and management.
Project: HertzBeat (Observability and Analysis / Observability)
File: http_sd.md

id: httpsd title: Monitoring Httpsd sidebar_label: Httpsd Monitor keywords: [open source monitoring tool, open source java monitoring tool, monitoring httpsd metrics] Collect and monitor the general performance Metrics of Httpsd. Protocol Usehttpsd Make sure your Register center is available > We currently support for `Consul` and `Nacos`. Add http_sd monitor and enter necessary info about Register center on Hertzbeat, such as host, port and so on. Click OK | Parameter name | Parameter help description | | | | | Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Task name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by Register center | | Discovery Client Type | Select one Register center that you want to monitor | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | - | -- | -- | | Address | | | | Port | | | | Response Time | ms | | | Metric name | Metric unit | Metric help description | | - | -- | -- | | Service Id | | | | Service Name | | | | Address | | | | Port | | | | Health Status | | Current health status of service |
Project: Netdata (Observability and Analysis / Observability)
File: tcp_orphans.md

This alert indicates that your system is experiencing high IPv4 TCP socket utilization, specifically orphaned sockets. Orphaned connections are those not attached to any user file handle. When these connections exceed the limit, they are reset immediately. The warning state is triggered when the percentage of used orphan IPv4 TCP sockets exceeds 25%, and the critical state is triggered when the value exceeds 50%. Check the current orphan socket usage To check the number of orphan sockets in your system, run the following command: ``` cat /proc/sys/net/ipv4/tcpmaxorphans ``` Identify the processes causing high orphan socket usage To identify the processes causing high orphan socket usage, you can use the `ss` command: ``` sudo ss -tan state time-wait state close-wait ``` Look for connections with a large number of orphan sockets and investigate the related processes. Increase the orphan socket limit If you need to increase the orphan socket limit to accommodate legitimate connections, you can update the value in the `/proc/sys/net/ipv4/tcpmaxorphans` file. Replace `{DESIRED_AMOUNT}` with the new limit: ``` echo {DESIREDAMOUNT} > /proc/sys/net/ipv4/tcpmax_orphans ``` Consider the kernel's penalty factor for orphan sockets (usually 2x or 4x) when determining the appropriate limit. Note: Be cautious when making system changes and ensure you understand the implications of updating these settings. Review and optimize application behavior Investigate the applications generating a high number of orphan sockets and consider optimizing their behavior. This may involve updating application settings or code to better manage network connections. Monitor your system Keep an eye on your system's orphan socket usage, particularly during peak hours. Adjust the limit as needed to accommodate legitimate connections.
Project: Teletrace (Observability and Analysis / Observability)
File: kubernetes.md

This tutorial will guide you through the process of installing Teletrace, using Helm. The Teletrace Helm chart is available on the and makes it easy to install and configure Teletrace in a Kubernetes cluster. A Kubernetes cluster running version 1.11 or later. installed and initialized in your cluster. Access to the Kubernetes cluster with sufficient privileges to create and manage resources. <!-- prettier-ignore-start --> Add the Teletrace Helm repository to your local Helm installation: ```sh helm repo add teletrace https://teletrace.github.io/helm-charts/ ``` Update the Helm repository to ensure that you have the latest version of the Teletrace Helm chart: ```sh helm repo update ``` Install Teletrace using Helm chart with the following command: ```sh helm install teletrace teletrace/teletrace --namespace teletrace --create-namespace ``` This command will install Teletrace in your Kubernetes cluster using the default configuration values specified in the Helm chart. Check the status of the Teletrace installation with the following command: ```sh kubectl get pods -n teletrace ``` This command will show the list of pods running in your Kubernetes cluster. You should see Teletrace pod running in your cluster. (Optional) Verify that Teletrace is running correctly by accessing the Teletrace UI. To access the UI, run the following command: ```sh kubectl port-forward svc/teletrace 8080:8080 -n teletrace ``` This command will create a port-forward to the Teletrace UI. You can now access the UI by opening your web browser and navigating to http://localhost:8080. (Optional) Customize the Teletrace installation by modifying the values in the Helm chart. You can modify the values in the Helm chart by creating a YAML file with your custom values and using the --values option when installing Teletrace. For example: ```sh helm install teletrace teletrace/teletrace -f my-values.yml --namespace teletrace --create-namespace ``` <!-- prettier-ignore-end --> In this tutorial, you learned how to install Teletrace using Helm chart. Helm chart simplifies the installation and management of Teletrace in a Kubernetes cluster. You can customize the installation by modifying the values in the Helm chart. With Teletrace installed, you can now use it to trace the requests and responses of your microservices applications.
Project: Checkmk (Observability and Analysis / Observability)
File: 16393.md

key | value | date | 2024-02-14T13:46:22+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes We recently made a change that would allow you to create a notification rule, via the REST-API using a custom plugin but also setting the option "cancelpreviousnotifications". However, an apache restart was required since we were verifying the custom plugin via the runtime generated schema. This werk fixes this issue by removing this verification from the schema and checking at the endpoint.
Project: SkyWalking (Observability and Analysis / Observability)
File: ES-Server-FAQ.md

Some new users may encounter the following issues: The performance of ElasticSearch is not as good as expected. For instance, the latest data cannot be accessed after some time. Or ERROR CODE 429. ``` Suppressed: org.elasticsearch.client.ResponseException: method [POST], host [http://127.0.0.1:9200], URI [/serviceinstanceinventory/type/6tcc-app-gateway-77b98ff6ff-crblx.cards00/update?refresh=true&timeout=1m], status line [HTTP/1.1 429 Too Many Requests] {"error":{"rootcause":[indices:data/write/update[s]]"}],"type":"esrejectedexecutionexception","reason":"rejected execution of org.elasticsearch.transport.TransportService$7@19a5cf02 on EsThreadPoolExecutor[name = elasticsearch-0/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@389297ad[Running, pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 147611]]"},"status":429} at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:705) ~[elasticsearch-rest-client-6.3.2.jar:6.3.2] at org.elasticsearch.client.RestClient.performRequest(RestClient.java:235) ~[elasticsearch-rest-client-6.3.2.jar:6.3.2] at org.elasticsearch.client.RestClient.performRequest(RestClient.java:198) ~[elasticsearch-rest-client-6.3.2.jar:6.3.2] at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:522) ~[elasticsearch ``` You could add the following config to `elasticsearch.yml`, and set the value based on your environment variable. ```yml threadpool.index.queuesize: 1000 threadpool.write.queuesize: 1000 index.maxresultwindow: 1000000 ``` For more information, see ElasticSearch's official documentation.
Project: Netdata (Observability and Analysis / Observability)
File: hdfs_num_failed_volumes.md

This alert is triggered when the number of failed volumes in your Hadoop Distributed File System (HDFS) cluster increases. A failed volume may be due to hardware failure or misconfiguration, such as duplicate mounts. When a single volume fails on a DataNode, the entire node may go offline depending on the `dfs.datanode.failed.volumes.tolerated` setting for your cluster. This can lead to increased network traffic and potential performance degradation as the NameNode needs to copy any under-replicated blocks lost on that node. Use the `dfsadmin -report` command to identify the DataNodes that are offline: ```bash root@netdata # dfsadmin -report ``` Find any nodes that are not reported in the output of the command. If all nodes are listed, you'll need to run the next command for each DataNode. Use the `hdfs dfsadmin -getVolumeReport` command, specifying the DataNode hostname and port: ```bash root@netdata # hdfs dfsadmin -getVolumeReport datanodehost:port ``` Connect to the affected DataNode and check its logs using `journalctl -xe`. If you have the Netdata Agent running on the DataNodes, you should be able to identify the problem. You may also receive alerts about the disks and mounts on this system. Based on the information gathered in the previous steps, take appropriate actions to resolve the issue. This may include: Repairing or replacing faulty hardware. Fixing misconfigurations such as duplicate mounts. Ensuring that the HDFS processes are running on the affected DataNode. Ensuring that the affected DataNode is properly communicating with the NameNode. Note: When working with HDFS, it's essential to have proper backups of your data. Netdata is not responsible for any loss or corruption of data, database, or software.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-strategy_create.md

category: Strategy apiurl: '/api/v1/strategy' title: "Create Strategy" type: 'POST' sample_doc: 'template.html' layout: default Required ```{ "tpl_id": 221, "tags": "", "run_end": "24:00", "run_begin": "00:00", "right_value": "1", "priority": 1, "op": "==", "note": "this is a test", "metric": "agent.alive", "max_step": 3, "func": "all(#3)" }``` ```Status: 200``` ``` { "id": 2, "tpl_id": 221, "tags": "", "run_end": "24:00", "run_begin": "00:00", "right_value": "1", "priority": 1, "op": "==", "note": "this is a test", "metric": "agent.alive", "max_step": 3, "func": "all(#3)" } ```
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleDown.md

Promscale instance is unreachable Monitoring data cannot be collected and as a result there is no visibility into the operations of promscale. Promscale operations may be affected, and it may not be possible to ingest or query metrics or tracing data. Check if Promscale is up and running Check if data is scraped in Prometheus Ensure that Promscale metric endpoint is being scraped by Prometheus
Project: Vector (Observability and Analysis / Observability)
File: reduce.md

title: Reduce description: Collapse multiple log events into a single event based on a set of conditions and merge strategies component_kind: transform layout: component tags: ["filter", "multiline", "component", "transform", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Elastic (Observability and Analysis / Observability)
File: to_radians.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a number in degrees to radians. ``` ROW deg = [90.0, 180.0, 270.0] | EVAL rad = TO_RADIANS(deg) ```
Project: Prometheus (Observability and Analysis / Observability)
File: remote_read_api.md

title: Remote Read API sort_rank: 7 This is not currently considered part of the stable API and is subject to change even between non-major version releases of Prometheus. This API provides data read functionality from Prometheus. This interface expects compression. The API definition is located . Request are made to the following endpoint. ``` /api/v1/read ``` This returns a message that includes a list of raw samples. These streamed chunks utilize an XOR algorithm inspired by the compression to encode the chunks. However, it provides resolution to the millisecond instead of to the second.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: webhook.md

title: Webhook Analytics Integration description: Integrate Flagsmith with your own infrastructure sidebar_label: Webhook hide_title: true sidebar_position: 100 You can integrate Flagsmith with your own data warehouse using our Webhook integration. The integration automatically sends the flag states for identified users as a webhook, to a URL you specify, for cohort analysis, A/B testing and more. The process is as follows: Write an endpoint that accepts the defined below Add the integration in Flagsmith, providing your URL created in the step above. You can also provide a Secret which will be . This will allow you to verify that the Webhook has come from Flagsmith. All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send the a full set of flag evaluations, traits and segments for that particular user to your webhook URL. Flagsmith will send a `POST` request to the Webhook url you provide, with the following payload in the body: ```json { "flags": [ { "enabled": false, "environment": 2, "feature": { "created_date": "2022-02-04T14:57:39.200798Z", "default_enabled": false, "description": null, "id": 1, "initial_value": null, "name": "12e12e", "type": "STANDARD" }, "feature_segment": null, "featurestatevalue": null, "id": 2, "identity": null }, { "enabled": true, "environment": 2, "feature": { "created_date": "2022-02-04T14:57:44.244575Z", "default_enabled": true, "description": null, "id": 2, "initial_value": null, "name": "gggg", "type": "STANDARD" }, "feature_segment": null, "featurestatevalue": null, "id": 4, "identity": null } ], "identity": "user_test", "segments": [ { "id": 1, "member": true, "name": "test_segment" } ], "traits": [ { "id": 4, "trait_key": "222", "trait_value": 333 }, { "id": 5, "trait_key": "aaa", "trait_value": "bbb" } ] } ``` Once the integration has been set up, you can start segmenting your data warehouse users based on the flags that they saw and the Segments that they are a member of. This allows you to enrich the data within your warehouse through Flagsmith. When your webhook secret is set, Flagsmith uses it to create a hash signature with each payload. This hash signature is passed with each request under the X-Flagsmith-Signature header that you need to validate at your end Compute an HMAC with the SHA256 hash function. Use request body (raw utf-8 encoded string) as the message and secret (utf8 encoded) as the Key. Here is one example in Python: ```python import hmac secret = "my shared secret" expected_signature = hmac.new( key=secret.encode(), msg=request_body, digestmod=hashlib.sha256, ).hexdigest() received_signature = request hmac.comparedigest(expectedsignature, received_signature) is True ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16331.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-01-29T10:17:43+00:00 level | 1 class | fix component | checks edition | cre Some mcafee services were not discovered because of the detection criteria. This has now been fixed by using the 'OBJECTID' for the detection.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.ContainerState.md

title: "Interface: ContainerState" linkTitle: "ContainerState" slug: "libk8scluster.ContainerState" .ContainerState running: `Object` | Name | Type | | : | : | | `startedAt` | `string` | _ terminated: `Object` | Name | Type | | : | : | | `containerID` | `string` | | `exitCode` | `number` | | `finishedAt` | `string` | | `message?` | `string` | | `reason` | `string` | | `signal?` | `number` | | `startedAt` | `string` | _ waiting: `Object` | Name | Type | | : | : | | `message?` | `string` | | `reason` | `string` |
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeManagedFields.md

title: "Interface: KubeManagedFields" linkTitle: "KubeManagedFields" slug: "libk8scluster.KubeManagedFields" .KubeManagedFields `deprecated` For backwards compatibility, please use KubeManagedFieldsEntry `KubeManagedFields` apiVersion: `string` APIVersion defines the version of this resource that this field set applies to. The format is "group/version" just like the top-level APIVersion field. It is necessary to track the version of a field set because it cannot be automatically converted. . _ fieldsType: `string` FieldsType is the discriminator for the different fields format and version. There is currently only one possible value: "FieldsV1" . _ fieldsV1: `object` FieldsV1 holds the first JSON version format as described in the "FieldsV1" type. . _ manager: `string` Manager is an identifier of the workflow managing these fields. . _ operation: `string` Operation is the type of operation which lead to this ManagedFieldsEntry being created. The only valid values for this field are 'Apply' and 'Update'. . _ subresource: `string` Subresource is the name of the subresource used to update that object, or empty string if the object was updated through the main resource. The value of this field is used to distinguish between managers, even if they share the same name. For example, a status update will be distinct from a regular update using the same manager name. Note that the APIVersion field is not related to the Subresource field and it always corresponds to the version of the main resource. . _ timestamp: `string` Time is the timestamp of when the ManagedFields entry was added.The timestamp will also be updated if a field is added, the manager changes any of the owned fields value or removes a field. The timestamp does not update when a field is removed from the entry because another manager took it over. .
Project: Beats (Observability and Analysis / Observability)
File: README.md

The script directory contains various scripts which exist to help testing aws module in metricbeat. Below is a brief description of each file / folder. | File / Folder | Description | |-|| | gettempcreds.go | Use MFA token to get temporary AWS credentials. | | sqssendreceive_delete.go | Get a list of SQS queues for a given region, send messages, receive messages and delete message from each queue. | | testcloudwatchmetricset.yml| Config file for testing using cloudwatch metricset to collect EC2 metrics and tags. |
Project: Checkmk (Observability and Analysis / Observability)
File: 16360.md

key | value | date | 2024-02-16T09:38:25+00:00 version | 2.4.0b1 class | feature edition | cre component | omd level | 1 compatible | yes To make it easier to detect certain security relevant events a dedicated security log is introduced. You can find it in `var/log/security.log`. The format of each line is: The date and time the logentry was created (local time) The security domain and the process id. The message as json with a `summary` and `details` key. The contents of the `details` vary by the domain. Currently the following domains exist: `application_errors`: e.g if a CSRF token could not be found/validated `auth`: e.g. successful / unsuccessful authentication attempts. (Successful authentication attempts without opening a session are currently not logged.) `service`: e.g. the start of a site `user_management`: e.g. change of a password Please note that this logfile is still subject to change. Additional events might be added and details may change with p-releases.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_roleBinding.KubeRoleBinding.md

title: "Interface: KubeRoleBinding" linkTitle: "KubeRoleBinding" slug: "libk8sroleBinding.KubeRoleBinding" .KubeRoleBinding `KubeRoleBinding` `Optional` apiVersion: `string` . _ 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: . _ roleRef: `Object` | Name | Type | | : | : | | `apiGroup` | `string` | | `kind` | `string` | | `name` | `string` | _ subjects: { `apiGroup`: `string` ; `kind`: `string` ; `name`: `string` ; `namespace`: `string` }[]
Project: Checkmk (Observability and Analysis / Observability)
File: 15298.md

key | value | compatible | yes version | 2.3.0b1 date | 2023-10-24T09:01:15+00:00 level | 1 class | fix component | agents edition | cre <a href="https://checkmk.com/werk/14839">Werk #14839</a> added the function <tt>listagg</tt> to one of our queries. Older versions of oracle database expect a <tt>WITHIN</tt> statement after the <tt>listagg</tt> function. This was added to assure compatibility with older databases.