Skip to content

OSSMDOC-133 Roll back autoscaling options in 4.3, 4.4, 4.5 branches. #27263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 9, 2021
Merged

OSSMDOC-133 Roll back autoscaling options in 4.3, 4.4, 4.5 branches. #27263

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 33 additions & 59 deletions modules/jaeger-config-collector.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,29 @@ The Jaeger Collector is the component responsible for receiving the spans that w

The collectors are stateless and thus many instances of Jaeger Collector can be run in parallel. Collectors require almost no configuration, except for the location of the Elasticsearch cluster.

.Jaeger Collector parameters
.Jaeger Collector parameters used by the Operator
[options="header"]
[cols="l, a, a"]
|===
|Parameter |Description |Values
|collector:
num-workers:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still going to cause confusion, as this option and the next are defined under collector/options, e.g.

collector:
  options:
    collector:
      num-workers: 50

whereas the replicas field is:

collector:
  replicas: 5

I think we need two tables - one for the parameters that are used by the operator (or k8s), and the other for the options that are passed to the component (collector in this case).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see if I've got the distinction clear before I start movings things around into new tables.

  • Parameters used by the operator are specified under the component in the YAML file (in this case under "collector")
  • Parameters specified under "component: options{}" are passed to the component

And is there somewhere where all this is written down? I've been trying to piece things together from various example files in the Jaeger Operator repo, but a definitive list would be really useful. The CLI flags (https://www.jaegertracing.io/docs/1.21/cli/#jaeger-collector-elasticsearch) don't really help in figuring out where the options would be nested in the configuration files.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, you have the distinction clear.

The CLI flags only appear in the component/options section (i.e. the second category), passed to the component.

Unfortunately the other types are not generated into easily understandable docs yet - there are some godocs: https://godoc.org/github.com/jaegertracing/jaeger-operator/pkg/apis/jaegertracing/v1

So for these, probably the examples are a good source still.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CLI flags only appear in the component/options section (i.e. the second category), passed to the component.

Well, that is actually very helpful. And thanks for the link to the godocs, I hadn't seen those before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@objectiser , this is somewhat of a stale PR. I'm creating a new issue to deal with splitting the table format so that
1 - we can move forward with removing this content from these branches and
2 - the tables get updated in the current and future branches.

JIRA is OSSMDOC-233.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @jpkrohling

|The number of workers pulling from the queue.
|Integer, for example, `50`

|collector:
queue-size:
|The size of the Collector queue.
|Integer, for example, `2000`

|collector:
replicas:
|Specifies the number of Collector replicas to create.
|Integer, for example, `5`
|===


.Jaeger parameters passed to the Collector
[options="header"]
[cols="l, a, a"]
|===
Expand All @@ -21,70 +43,22 @@ The collectors are stateless and thus many instances of Jaeger Collector can be
|Configuration options that define the Jaeger Collector.
|

|autoscale:
|This parameter controls whether to enable/disable autoscaling for the Collector. Set to `false` to explicitly disable autoscaling. Note that autoscaling is only supported for Jaeger 1.20 or later.
|`true`/`false`

|kafka:
producer:
topic: jaeger-spans
|options:
kafka:
producer:
topic: jaeger-spans
|The `topic` parameter identifies the Kafka configuration used by the collector to produce the messages, and the ingester to consume the messages.
|Label for the producer

|kafka:
producer:
brokers: my-cluster-kafka-brokers.kafka:9092
|options:
kafka:
producer:
brokers: my-cluster-kafka-brokers.kafka:9092
|Identifies the Kafka configuration used by the Collector to produce the messages. If brokers are not specified, and you have AMQ Streams 1.4.0+ installed, Jaeger will self-provision Kafka.
|

|log-level:
|options:
log-level:
|Logging level for the collector.
|`trace`, `debug`, `info`, `warning`, `error`, `fatal`, `panic`

|maxReplicas:
|Specifies the maximum number of replicas to create when autoscaling the Collector.
|Integer, for example, `100`

|num-workers:
|The number of workers pulling from the queue.
|Integer, for example, `50`

|queue-size:
|The size of the Collector queue.
|Integer, for example, `2000`

|replicas:
|Specifies the number of Collector replicas to create.
|Integer, for example, `5`
|===


== Configuring the Collector for autoscaling

[NOTE]
====
Autoscaling is only supported for Jaeger 1.20 or later.
====

You can configure the Collector to autoscale; the Collector will scale up or down based on the CPU and/or memory consumption. Configuring the Collector to autoscale can help you ensure your Jaeger environment scales up during times of increased load, and scales down when less resources are needed, saving on costs. You configure autoscaling by setting the `autoscale` parameter to `true` and specifying a value for `.spec.collector.maxReplicas` along with a reasonable value for the resources that you expect the Collector’s pod to consume. If you do not set a value for `.spec.collector.maxReplicas` the Operator will set it to `100`.

By default, when there is no value provided for `.spec.collector.replicas`, the Jaeger Operator creates a horizontal pod autoscaler (HPA) configuration for the Collector. For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].

The following is an example autoscaling configuration, setting the Collector’s limits as well as the maximum number of replicas:

.Collector autoscaling example
[source,yaml]
----
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: simple-prod
spec:
strategy: production
collector:
maxReplicas: 5
resources:
limits:
cpu: 100m
memory: 128Mi
----
76 changes: 24 additions & 52 deletions modules/jaeger-config-ingester.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,20 @@ This REFERENCE module included in the following assemblies:

Ingester is a service that reads from a Kafka topic and writes to another storage backend (Elasticsearch). If you are using the `allInOne` or `production` deployment strategies, you do not need to configure the Ingester service.

.Jaeger Ingester parameters
.Jaeger Ingester parameters used by the Operator
[options="header"]
[cols="l, a, a"]
|===
|Parameter |Description |Values
|ingester:
deadlockInterval:
| Specifies the interval (in seconds or minutes) that the Ingester should wait for a message before terminating.
The deadlock interval is disabled by default (set to 0), to avoid the Ingester being terminated when no messages arrive while the system is being initialized.
|Minutes and seconds, for example, `1m0s`. Default value is `0`.
|===


.Jaeger parameters passed to the Ingester
[options="header"]
[cols="l, a, a"]
|===
Expand All @@ -20,35 +33,24 @@ Ingester is a service that reads from a Kafka topic and writes to another storag
|Configuration options that define the Ingester service.
|

|autoscale:
|This parameter controls whether to enable/disable autoscaling for the Ingester. Autoscaling is enabled by default. Set to `false` to explicitly disable autoscaling. Note that autoscaling is only supported for Jaeger 1.20 or later.
|`true`/`false`

|kafka:
consumer:
topic:
|options:
kafka:
consumer:
topic:
|The `topic` parameter identifies the Kafka configuration used by the collector to produce the messages, and the ingester to consume the messages.
|Label for the consumer. For example, `jaeger-spans`.

|kafka:
consumer:
brokers:
|options:
kafka:
consumer:
brokers:
|Identifies the Kafka configuration used by the Ingester to consume the messages.
|Label for the broker, for example, `my-cluster-kafka-brokers.kafka:9092`.

|ingester:
deadlockInterval:
| Specifies the interval (in seconds or minutes) that the Ingester should wait for a message before terminating.
The deadlock interval is disabled by default (set to 0), to avoid the Ingester being terminated when no messages arrive while the system is being initialized.
|Minutes and seconds, for example, `1m0s`. Default value is `0`.

|log-level:
|options:
log-level:
|Logging level for the Ingester.
|Possible values: `trace`, `debug`, `info`, `warning`, `error`, `fatal`, `panic`.

|maxReplicas:
|Specifies the maximum number of replicas to create when autoscaling the Ingester.
|Integer, for example, `100`.
|===

.Streaming Collector and Ingester example
Expand Down Expand Up @@ -80,33 +82,3 @@ spec:
es:
server-urls: http://elasticsearch:9200
----

== Configuring Ingester for autoscaling

[NOTE]
====
Autoscaling is only supported for Jaeger 1.20 or later.
====

You can configure the Ingester to autoscale; the Ingester will scale up or down based on the CPU and/or memory consumption. Configuring the Ingester to autoscale can help you ensure your Jaeger environment scales up during times of increased load, and scales down when less resources are needed, saving on costs. You configure autoscaling by setting the `autoscale` parameter to `true` and specifying a value for `.spec.ingester.maxReplicas` along with a reasonable value for the resources that you expect the Ingester's pod to consume. If you do not set a value for `.spec.ingester.maxReplicas` the Operator will set it to `100`.

By default, when there is no value provided for `.spec.ingester.replicas`, the Jaeger Operator creates a horizontal pod autoscaler (HPA) configuration for the Ingester. For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].

The following is an example autoscaling configuration, setting the Ingester’s limits as well as the maximum number of replicas:

.Ingester autoscaling example
[source,yaml]
----
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: simple-streaming
spec:
strategy: streaming
ingester:
maxReplicas: 8
resources:
limits:
cpu: 100m
memory: 128Mi
----