cwielenb/CNCF-Dataset huggingface dataset:
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: sizing-and-scaling.md

title: Sizing and Scaling description: Sizing and Scaling Flagsmith sidebar_position: 80 Flagsmith has a very simple architecture, making it well understood when it comes to serving high loads. Generally this component is not put under any sort of significant load. It can be load balanced if required. It does not require sticky-sessions. The API is completely stateless. This means it can scale out behind a load balancer almost perfectly. As an example, when running on AWS ECS/Fargate we run with: `cpu=1024` `memory=2048` In terms of auto scaling, we recommend basing the autoscaling off the `ECSServiceAverageCPUUtilization` metric, with a `target_value` of `50` and a 30 second cool-down timeout. Our recommendation is to first scale the database up with a more powerful single server. Once the database connections have been saturated by the API cluster, adding read replicas to the database solves the next bottleneck of database connections. Flagsmith can be set up to handle as many read replicas as needed. To add replicas, you'll need to set the `REPLICADATABASEURLS` environment variable with a comma separated list of database urls. Example: ``` REPLICADATABASEURLS: postgres://user:password@replica1.database.host:5432/flagsmith,postgres://user:password@replica2.database.host:5432/flagsmith ``` :::tip Use the `REPLICADATABASEURLS_DELIMITER` environment variable if you are using any `,` characters in your passwords. ::: In addition to typical read replicas, which usually exist locally in the same data centre to the application. There is also support for replicas across regions via the `CROSSREGIONREPLICADATABASEURLS` environment variable which is set in the same way as the `REPLICADATABASEURLS` with cross region replicas having their own matching CROSSREGIONREPLICADATABASEURLS_DELIMITER which also defaults to `,` as above. Cross region replicas are only used once all typical replicas have gone offline, since the performance characteristics wouldn't be favorable to spread replica load at longer latencies. Both `REPLICADATABASEURLS` and `CROSSREGIONREPLICADATABASEURLS` can be used alone or simultaneously. To support different configurations there are two different replication strategies available. By setting `REPLICAREADSTRATEGY` to `DISTRIBUTED` (the default option) the load to the replicas is distributed evenly. If your use-case, on the otherhand, is to utilize fallback replicas (primary, secondary, etc) the `REPLICAREADSTRATEGY` should be set to `SEQUENTIAL` so a replica is only used if all the other replica's preceding it have gone offline. This strategy is applicable to both typical replicas as well as to cross region replicas. We would also recommend testing in your environment as it generally optimises database connections and reduces the load on the database.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: zebrium.md

Zebrium is a new that uses Machine Learning to detect incidents and their root cause in your environments completely unsupervised. This means instead of you having to configure lists of alert rules to tell your monitoring solution what to look for, you just send your logs, metrics and (in future) traces to Zebrium, and Zebrium will alert you to incidents and their root cause with no configuration in real-time! Because our environments are getting more complex with Cloud, Containers/Kubernetes and Microservices, this provides a more scalable approach to catching issues than having to invest time and effort into setting up and maintaining long lists of alert rules. It also alerts you to failure modes you weren't aware of, and also significantly reduces Mean-Time-To-Resolution searching through your logs for the root cause! After Maya Data used Litmus themselves to evaluate the effectiveness of Zebrium's machine learning approach on their own Kubernetes environments with a 100% detection rate, we thought it would be a great idea to use Litmus ourselves for our own testing and also to provide a demo/trial environment that new users could spin up and try out quickly to test Zebrium's solution themselves. You can read full details here: We have created an that contains scripts and Litmus experiment configurations to quickly spin up and deploy applications to a GKE cluster, and then execute Litmus Chaos Tests, using a couple of commands. This enables us to provide a fully reproducable environment for testing the Zebrium solution. When used with Zebrium, each experiment will create a new alert with an incident and show the correct root cause, making it easy to see the logs and what was impacted during the Litmus experiment. This is completely unsupervised using only Machine Learning, and can also be applied to other clusters running Litmus to help understand the impact of experiments running in your Kubernetes environment. Because Litmus can be deployed in-cluster, without any external dependencies, and all experiments can be scripted and managed in source control, Litmus has provided a very easy way to provide a scriptable, reproducable test of Zebrium's machine learning solution. Please at Zebrium to test it for yourself.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: system-limits.md

title: System Limits In order to ensure consistent performance, Flagsmith has the following limitations. 400 Features per Project 100 Segments per Project 100 Segment Overrides per Environment 100 Segment Rules Conditions Maximum size of a Flag String Value is 20,000 bytes Maximum size of an Identity Trait Value is 2,000 bytes Maximum size of a Segment Rule Value is 1,000 bytes Requests made to (i.e., non-SDK endpoints) are subject to a default rate limit of 500 requests per minute. If you are self-hosting, you have the flexibility to modify this limit by adjusting the value of the environment variable `USERTHROTTLERATE`. Please contact us if you want to override the current system limits. You can modify the system limits on a per-Project basis. These limits are defined in the database against the Project. The easiest way to modify them is with the interface.
Project: Grafana (Observability and Analysis / Observability)
File: configure-team-sync.md

aliases: ../../auth/team-sync/ ../../enterprise/team-sync/ description: Learn how to use Team Sync to synchronize between your authentication provider teams and Grafana teams. labels: products: cloud enterprise title: Configure Team Sync weight: 1000 Team sync lets you set up synchronization between your auth providers teams and teams in Grafana. This enables LDAP, OAuth, or SAML users who are members of certain teams or groups to automatically be added or removed as members of certain teams in Grafana. Note: Available in and . Grafana keeps track of all synchronized users in teams, and you can see which users have been synchronized in the team members list, see `LDAP` label in screenshot. This mechanism allows Grafana to remove an existing synchronized user from a team when its group membership changes. This mechanism also enables you to manually add a user as member of a team, and it will not be removed when the user signs in. This gives you flexibility to combine LDAP group memberships and Grafana team memberships. Currently the synchronization only happens when a user logs in, unless LDAP is used with the active background synchronization that was added in Grafana 6.3. <div class="clearfix"></div> If you have already grouped some users into a team, then you can synchronize that team with an external group. In Grafana, navigate to Administration > Users and access > Teams. Select a team. Go to the External group sync tab, and click Add group. Insert the value of the group you want to sync with. This becomes the Grafana `GroupID`. Examples: For LDAP, this is the LDAP distinguished name (DN) of LDAP group you want to synchronize with the team. For Auth Proxy, this is the value we receive as part of the custom `Groups` header. Click Add group to save. Group matching is case insensitive. When using LDAP, you can use a wildcard (\*) in the common name attribute (CN) to match any group in the corresponding Organizational Unit (OU). Ex: `cn=*,ou=groups,dc=grafana,dc=org` can be matched by `cn=users,ou=groups,dc=grafana,dc=org`
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-zabbix.md

The Zabbix receiver accepts metrics of format into the . Zabbix Agent is based on GPL-2.0 License. ```yaml receiver-zabbix: selector: ${SWRECEIVERZABBIX:default} default: port: 10051 host: 0.0.0.0 activeFiles: agent ``` The Zabbix receiver is configured via a configuration file that defines everything related to receiving from agents, as well as which rule files to load. The OAP can load the configuration at bootstrap. If the new configuration is not well-formed, the OAP fails to start up. The files are located at `$CLASSPATH/zabbix-rules`. The file is written in YAML format, defined by the scheme described below. Square brackets indicate that a parameter is optional. An example for Zabbix agent configuration could be found . You can find details on Zabbix agent items from . ```yaml initExp: <string> metricPrefix: <string> expPrefix: <string> expSuffix: <string> requiredZabbixItemKeys: <zabbix item keys> entities: hostPatterns: <regex string> labels: [- <labels> ] metrics: [ - <metrics_rules> ] ``` ```yaml name: <string> [value: <string>] [fromItem: <string>] ``` ```yaml name: <string> exp: <string> ``` For more on MAL, please refer to .
Project: Netdata (Observability and Analysis / Observability)
File: consul_raft_leader_last_contact_time.md

This alert monitors the time since the Consul Raft leader server was last able to contact its follower nodes. If the time since the last contact exceeds the warning or critical thresholds, the alert will be triggered. High values indicate a potential issue with the Consul Raft leader's connection to its follower nodes. Check Consul logs Inspect the logs of the Consul leader server and follower nodes for any errors or relevant information. You can find the logs in `/var/log/consul` by default. Verify Consul agent health Ensure that the Consul agents running on the leader and follower nodes are healthy. Use the following command to check the overall health: ``` consul members ``` Review networking connectivity Check the network connectivity between the leader and follower nodes. Verify the nodes are reachable, and there are no firewalls or security groups blocking the necessary ports. Consul uses these ports by default: Server RPC (8300) Serf LAN (8301) Serf WAN (8302) HTTP API (8500) DNS Interface (8600) Monitor Consul server's resource usage Ensure that the Consul server isn't facing any resource constraints, such as high CPU, memory, or disk usage. Use system monitoring tools like `top`, `vmstat`, or `iotop` to observe resource usage and address bottlenecks. Verify the Consul server configuration Examine the Consul server's configuration file (usually located at `/etc/consul/consul.hcl`) and ensure that there are no errors, inconsistencies, or misconfigurations with server addresses, datacenter names, or communication settings.
Project: Thanos (Observability and Analysis / Observability)
File: integrations.md

is a common proto interface for gRPC component that can connect to in order to fetch the metric series. Natively Thanos implements (local Prometheus data), and . This solves fetching series from Prometheus or Prometheus TSDB format, however same interface can be used to fetch metrics from other storages. Below you can find some public integrations with other systems through StoreAPI: is an OpenTSDB integration service which can connect your OpenTSDB cluster to Thanos. Geras exposes the Thanos Storage API, thus other Thanos components can query OpenTSDB via Geras, providing a unified query interface over OpenTSDB and Prometheus. Although OpenTSDB is able to aggregate the data, it's not supported by Geras at the moment. is another StoreAPI integration from our friends at G-Research. It's a proxy, that allows exposing any Thanos service (or anything that exposes gRPC StoreAPI e.g. ) via Prometheus protocol. This means that you can connect Thanos and expose its data to any remote-read compatible applications including
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_storageClass.StorageClass.md

title: "Class: StorageClass" linkTitle: "StorageClass" slug: "libk8sstorageClass.StorageClass" .StorageClass `any` `StorageClass` new StorageClass(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeStorageClass\>('storageClass').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `apiInfo` | { `group`: `string` ; `resource`: `string` ; `version`: `string` }[] | | `delete` | (`name`: `string`, `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `get` | (`name`: `string`, `cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `isNamespaced` | `boolean` | | `list` | (`cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `patch` | (`body`: `OpPatch`, `cluster?`: `string`) => `Promise`<`any`\> | | `post` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `put` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeStorageClass\>('storageClass').className `get` provisioner(): `any` `any` _ `get` reclaimPolicy(): `any` `any` _ `get` volumeBindingMode(): `any` `any` _ `Static` `get` listRoute(): `string` `string` _ `Static` `get` pluralName(): `string` `string` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeStorageClass\>('storageClass').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeStorageClass\>('storageClass').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeStorageClass\>('storageClass').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeStorageClass\>('storageClass').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeStorageClass\>('storageClass').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeStorageClass\>('storageClass').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeStorageClass\>('storageClass').useList
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: socket.md

title: 'Using snapshot socket' weight: 20 description: > Gather information about TCP and UDP sockets. The snapshot socket gadget gathers information about TCP and UDP sockets. We will start this demo by using nginx to create a web server on port 80: ```bash $ kubectl create ns test-socketcollector namespace/test-socketcollector created $ kubectl run --restart=Never -n test-socketcollector --image=nginx nginx-app --port=80 pod/nginx-app created ``` Wait for the pod to get ready: ```bash $ kubectl wait --timeout=-1s -n test-socketcollector --for=condition=ready pod/nginx-app ; kubectl get pod -n test-socketcollector pod/nginx-app condition met NAME READY STATUS RESTARTS AGE nginx-app 1/1 Running 0 46s ``` We will now use the snapshot socket gadget to retrieve the TCP/UDP sockets information of the nginx-app pod. Notice we are filtering by namespace but we could have done it also using the podname or labels: ```bash $ kubectl gadget snapshot socket -n test-socketcollector K8S.NODE K8S.NAMESPACE K8S.POD PROTOCOL SRC DST STATUS minikube-docker test-socketcollect nginx-app TCP r/0.0.0.0:80 r/0.0.0.0:0 LISTEN ``` In the output, "SRC" is the local IP address and port number pair. If connected, "DST" is the remote IP address and port number pair, otherwise, it will be "0.0.0.0:0". While "STATUS" is the internal status of the socket. Now, modify the nginx configuration to listen on port 8080 instead of 80 and reload the daemon: ```bash $ kubectl exec -n test-socketcollector nginx-app -- /bin/bash -c "sed -i 's/listen \+80;/listen\t8080;/g' /etc/nginx/conf.d/default.conf && exec nginx -s reload" [...] signal process started ``` Now, we can check again with the snapshot socket gadget what the active socket is: ```bash K8S.NODE K8S.NAMESPACE K8S.POD PROTOCOL SRC DST STATUS minikube-docker test-socketcollect nginx-app TCP r/0.0.0.0:8080 r/0.0.0.0:0 LISTEN ``` Delete test namespace: ```bash $ kubectl delete ns test-socketcollector namespace "test-socketcollector" deleted ``` The `snapshot socket` is not available on `ig` yet. Please check https://github.com/inspektor-gadget/inspektor-gadget/issues/744.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: DOCKERHUB.md

<p align="center"> <img width="250" height="238" src="https://github.com/thomaspoignant/go-feature-flag/raw/main/logo.png" alt="go-feature-flag logo" /> </p> <p align="center"> <img alt="Docker Image Version" src="https://img.shields.io/docker/v/thomaspoignant/go-feature-flag?sort=semver&color=green"/> <img alt="Docker Image Size" src="https://img.shields.io/docker/image-size/thomaspoignant/go-feature-flag?sort=semver"/> <img alt="Docker Hub downloads" src="https://img.shields.io/docker/pulls/thomaspoignant/go-feature-flag?logo=docker"/> <a href="https://github.com/thomaspoignant/go-feature-flag/blob/main/LICENSE"><img src="https://img.shields.io/github/license/thomaspoignant/go-feature-flag" alt="License"/></a> <a href="https://gofeatureflag.org/slack"><img src="https://img.shields.io/badge/join-us%20on%20slack-gray.svg?longCache=true&logo=slack&colorB=green" alt="Join us on slack"></a> </p> The GO Feature Flag Relay Proxy retrieve your feature flag configuration file using SDK and expose APIs to get your flags variations. It lets a number of servers to connect to a single configuration file. This can be useful if you want to use the same feature flags configuration file for frontend and backend, this allows to be language agnostic by using standard protocol. For more information about GO Feature Flag Relay Proxy, please visit . This default distribution is the official distribution for `go-feature-flag`. Where to file issues: ). Source are available in . All versions are available in the . Release notes are available . `go-feature-flag` requires a configuration file to be used. By default, we expect to have this configuration file in the `/goff` directory of the container and the file should be named `goff-proxy.yaml`. The default port used for the service is `1031`. ```shell docker run \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ gofeatureflag/go-feature-flag:latest ``` This is a small example on how to run `go-feature-flag` locally. ```shell curl https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/cmd/relayproxy/testdata/config/valid-file.yaml -o goff-proxy.yaml docker run \ -p 1031:1031 \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ gofeatureflag/go-feature-flag:latest curl -X 'POST' \ 'http://localhost:1031/v1/feature/flag-only-for-admin/eval' -H 'accept: application/json' -H 'Content-Type: application/json' \ -d '{ "user": { "key": "contact@gofeatureflag.org", "anonymous": true, "custom": { "admin": true, "email": "contact@gofeatureflag.org" }}, "defaultValue": "false"}' ``` View information for the software contained in this image. This project is open for contribution, see the for some helpful tips.
Project: SkyWalking (Observability and Analysis / Observability)
File: http-restful-uri-pattern.md

As introduced in the doc, HTTP Restful URIs are identified as endpoints. With some additional rules, we can identify the parameters in the URI and group the endpoints in case of annoying and huge size of endpoint candidates with low value of the metrics. In the ML/AI specific fields, decision trees or neural networks can be trained on labeled URI data to automatically recognize and classify different URI patterns, as well as many other ways. In this pipeline, OAP has the capabilities to cache the URI candidates with occurrence count, and push the data to 3rd party for further analysis. Then OAP would pull the analyzed results for processing the further telemetry traffic. `uriRecognitionServerAddr` and `uriRecognitionServerPort` are the configurations to set up the remote URI recognition server. The URI recognition server is a gRPC server, which is defined in . ```protobuf service HttpUriRecognitionService { // Sync for the pattern recognition dictionary. rpc fetchAllPatterns(HttpUriRecognitionSyncRequest) returns (HttpUriRecognitionResponse) {} // Feed new raw data and matched patterns to the AI-server. rpc feedRawData(HttpUriRecognitionRequest) returns (google.protobuf.Empty) {} } ``` fetchAllPatterns service fetchAllPatterns is up and running in 1 minute period from every OAP to fetch all recognized patterns from the remote server. feedRawData service feedRawData is running in 25-30 minutes period to push the raw data to the remote server for training. `core/maxHttpUrisNumberPerService` The max number of HTTP URIs per service for further URI pattern recognition. `core/syncPeriodHttpUriRecognitionPattern` The period of HTTP URI pattern recognition(feedRawData). Unit is second, 10s by default. `core/trainingPeriodHttpUriRecognitionPattern` The training period of HTTP URI pattern recognition(fetchAllPatterns). Unit is second, 60s by default. is an Apache 2.0 licensed implementation for the URI recognition, and natively supports `URIRecognition.proto` defined in OAP.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v5.0.md

title: "Grafana Mimir Helm chart version 5.0 release notes" menuTitle: "V5.0 release notes" description: "Release notes for Grafana Mimir Helm chart version 5.0" weight: 300 Grafana Labs is excited to announce version 5.0 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.9 or Grafana Enterprise Metrics (GEM) v2.9. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Note: For a migration guide from `mimir-distributed` version 4.X to 5.0, see . Breaking change: PodSecurityPolicy objects are no longer rendered on Kubernetes versions 1.24 or higher. This resource type was deprecated in Kubernetes version 1.21 and was removed in version 1.25. Due to how Helm manages release histories, the `mimir-distributed` Helm chart can no longer be upgraded if a PodSecurityPolicy was present during a Kubernetes upgrade from 1.24 to 1.25. In order to remediate this, `mimir-distributed` no longer renders the PodSecurityPolicy on Kubernetes 1.24. For a migration guide from `mimir-distributed` version 4.X to 5.0, see . Notable enhancements are as follows: Use metadata cache for ruler bucket scans. This greatly reduces pressure to the object store by the ruler. Support metricRelabelings in the monitoring serviceMonitor resources via `metaMonitoring.serviceMonitor.metricRelabelings`. Increase the default number of ingester Pods that can restart at a time in a multi-zone deployment. This speeds up deployments with more than 25 ingesters per zone.