From 672c17eb691e236b035e2537bf3c89cec26e4dc4 Mon Sep 17 00:00:00 2001 From: gentksb <36843875+gentksb@users.noreply.github.com> Date: Tue, 2 Jun 2026 20:31:28 +0900 Subject: [PATCH 1/2] Add Japanese translations for v6.85 --- content/ja/_index.md | 66 +-- content/ja/browse/_index.md | 6 +- .../2-1-configuration.md | 100 ++++ .../3-dropping-spans/3-1-configuration.md | 75 +++ .../4-sensitive-data/4-1-configuration.md | 124 +++++ .../6-routing-data/6-2-pipelines.md | 109 ++++ .../13-observing-business-journeys/_index.md | 4 +- content/ja/ninja-workshops/_index.md | 11 +- .../1-introduction/_index.md | 57 ++ .../2-related-content/_index.md | 79 +++ .../3-autodetect/_index.md | 130 +++++ .../4-tag-spotlight/_index.md | 204 ++++++++ .../5-log-observer-ai/_index.md | 255 +++++++++ .../6-apm-assistant/_index.md | 262 ++++++++++ .../10-using-ai-in-o11y/7-wrap-up/_index.md | 243 +++++++++ .../ai/10-using-ai-in-o11y/_index.md | 31 ++ .../ai/18-agentic-ai/1-connect-to-instance.md | 77 +++ .../10-add-ai-defense-instrumentation.md | 222 ++++++++ .../18-agentic-ai/11-detect-security-risks.md | 208 ++++++++ .../12-explore-other-ai-frameworks.md | 227 ++++++++ .../ai/18-agentic-ai/13-wrapup.md | 19 + .../2-review-azure-ai-metrics.md | 63 +++ .../ai/18-agentic-ai/3-deploy-collector.md | 131 +++++ .../4-1-request-lifecycle.md | 60 +++ .../4-2-shared-state.md | 58 +++ .../4-3-orchestration.md | 78 +++ .../4-4-graph-definition.md | 65 +++ .../4-5-node-definition.md | 61 +++ .../4-6-message-abstractions.md | 49 ++ .../4-7-llm-creation.md | 51 ++ .../4-8-decomposition-pattern.md | 66 +++ .../4-review-agentic-ai-app/_index.md | 49 ++ .../ai/18-agentic-ai/5-deploy-the-app.md | 185 +++++++ .../ai/18-agentic-ai/6-instrument-the-app.md | 245 +++++++++ .../7-review-agent-trace-data.md | 71 +++ .../ai/18-agentic-ai/8-add-tool-calls.md | 492 ++++++++++++++++++ .../18-agentic-ai/9-detect-quality-issue.md | 185 +++++++ .../ai/18-agentic-ai/_index.md | 29 ++ content/ja/ninja-workshops/ai/_index.md | 9 + .../1-download-agent/_index.md | 45 ++ .../2-install-agent/_index.md | 126 +++++ .../3-generate-application-load/_index.md | 147 ++++++ .../4-apm-core-concepts/_index.md | 91 ++++ .../5-configure-controller/_index.md | 73 +++ .../6-apm-part1/_index.md | 108 ++++ .../7-apm-part2/_index.md | 106 ++++ .../_index.md | 42 ++ .../1-lab-prerequisites/_index.md | 107 ++++ .../2-deploy-server-agent-option-1/_index.md | 82 +++ .../3-deploy-server-agent/_index.md | 88 ++++ .../4-monitor-server-health/_index.md | 111 ++++ .../5-apm-to-server/_index.md | 32 ++ .../2-server-visibility-monitoring/_index.md | 43 ++ .../1-lab-prerequisites/_index.md | 139 +++++ .../2-enable-analytics/_index.md | 35 ++ .../_index.md | 104 ++++ .../_index.md | 181 +++++++ .../5-dashboard-components/_index.md | 135 +++++ .../6-build-your-dashboard/_index.md | 15 + .../15-appd-workshop/3-business-iq/_index.md | 33 ++ .../1-lab-prerequisites/_index.md | 119 +++++ .../2-create-browser-application/_index.md | 53 ++ .../3-configure-agent-injection/_index.md | 55 ++ .../_index.md | 152 ++++++ .../_index.md | 117 +++++ .../4-brum-monitoring/_index.md | 37 ++ .../1-lab-prerequisites/_index.md | 119 +++++ .../2-download-database-agent/_index.md | 38 ++ .../3-install-database-agent/_index.md | 77 +++ .../4-configure-database-collector/_index.md | 73 +++ .../_index.md | 102 ++++ .../_index.md | 77 +++ .../5-database-monitoring/_index.md | 39 ++ .../1-remote-installation/1-prerequisites.md | 95 ++++ .../1-remote-installation/2-configuration.md | 310 +++++++++++ .../1-remote-installation/3-installation.md | 229 ++++++++ .../4-troubleshooting.md | 465 +++++++++++++++++ .../1-remote-installation/_index.md | 81 +++ .../2-jenkins-automation/1-architecture.md | 306 +++++++++++ .../2-jenkins-automation/2-jenkins-setup.md | 294 +++++++++++ .../3-pipeline-creation.md | 268 ++++++++++ .../4-deployment-workflow.md | 366 +++++++++++++ .../2-jenkins-automation/_index.md | 80 +++ .../3-github-actions/1-architecture.md | 312 +++++++++++ .../3-github-actions/2-github-setup.md | 286 ++++++++++ .../3-github-actions/3-workflows.md | 229 ++++++++ .../3-github-actions/4-running-workflows.md | 401 ++++++++++++++ .../6-smartagent/3-github-actions/_index.md | 93 ++++ .../4-ansible-automation/2-setup.md | 95 ++++ .../4-ansible-automation/3-deployment.md | 25 + .../4-ansible-automation/_index.md | 72 +++ .../15-appd-workshop/6-smartagent/_index.md | 155 ++++++ .../apm/15-appd-workshop/_index.md | 38 ++ .../apm/17-appd-ingest/1-overview/_index.md | 105 ++++ .../2-run-with-appd/1-build-the-app.md | 91 ++++ .../2-run-with-appd/2-download-appd-agent.md | 32 ++ .../2-run-with-appd/3-run-and-verify.md | 98 ++++ .../17-appd-ingest/2-run-with-appd/_index.md | 12 + .../1-install-otel-collector.md | 161 ++++++ .../3-enable-dual-mode/2-enable-dual-mode.md | 96 ++++ .../3-enable-dual-mode/3-verify-in-both.md | 57 ++ .../3-enable-dual-mode/_index.md | 12 + .../4-global-data-links/_index.md | 77 +++ .../apm/17-appd-ingest/5-wrap-up/_index.md | 52 ++ .../apm/17-appd-ingest/_index.md | 15 + content/ja/ninja-workshops/apm/_index.md | 9 + .../1-petclinic-monolith/1-otel-collector.md | 76 +++ .../2-building-petclinic.md | 55 ++ .../1-petclinic-monolith/3-auto-discovery.md | 64 +++ .../1-petclinic-monolith/4-rum.md | 78 +++ .../1-petclinic-monolith/5-log-observer.md | 24 + .../1-petclinic-monolith/_index.md | 36 ++ .../1-architecture/_index.md | 18 + .../2-preparation/1-otel.md | 138 +++++ .../2-preparation/2-petclinic.md | 120 +++++ .../2-preparation/_index.md | 61 +++ .../3-verify-setup/_index.md | 28 + .../4-apm/1-patching-deployment.md | 79 +++ .../4-apm/2-apm-data.md | 16 + .../2-petclinic-kubernetes/4-apm/_index.md | 49 ++ .../5-traces/1-service-map.md | 19 + .../5-traces/2-trace.md | 23 + .../5-traces/3-spans.md | 46 ++ .../5-traces/4-red-metrics.md | 13 + .../2-petclinic-kubernetes/5-traces/_index.md | 13 + .../6-profiling-db-query/1-profiling.md | 69 +++ .../6-profiling-db-query/2-waterfall.md | 32 ++ .../6-profiling-db-query/3-dbquery.md | 54 ++ .../6-profiling-db-query/_index.md | 16 + .../7-log-observer-connect/1-view-logs.md | 21 + .../2-related-content.md | 15 + .../7-log-observer-connect/_index.md | 17 + .../8-rum/1-rum-tour.md | 22 + .../8-rum/2-rum-tour.md | 14 + .../8-rum/3-rum-tour.md | 19 + .../2-petclinic-kubernetes/8-rum/_index.md | 53 ++ .../9-wrap-up/_index.md | 17 + .../2-petclinic-kubernetes/_index.md | 32 ++ .../1-automatic-discovery/_index.md | 9 + .../1-installation/1-confirmation.md | 310 +++++++++++ .../1-installation/_index.md | 41 ++ .../2-extensions/1-health.md | 58 +++ .../2-extensions/2-performance.md | 9 + .../2-extensions/3-zpages.md | 363 +++++++++++++ .../2-extensions/_index.md | 37 ++ .../3-receivers/1-hostmetrics.md | 44 ++ .../3-receivers/2-prometheus.md | 35 ++ .../3-receivers/3-other-receivers.md | 170 ++++++ .../3-receivers/_index.md | 39 ++ .../4-processors/1-batch-processor.md | 15 + .../4-processors/2-resource-detection.md | 53 ++ .../4-processors/3-attributes.md | 200 +++++++ .../4-processors/_index.md | 37 ++ .../5-exporters/1-otlphttp.md | 199 +++++++ .../5-exporters/_index.md | 39 ++ .../6-service/1-hostmetrics.md | 27 + .../6-service/2-prometheus.md | 27 + .../6-service/3-resourcedetection.md | 27 + .../6-service/4-attributes.md | 27 + .../6-service/5-otlphttp.md | 243 +++++++++ .../6-service/_index.md | 26 + .../7-visualisation/index.md | 38 ++ .../8-develop/1-project-setup.md | 34 ++ .../8-develop/2-configuration.md | 93 ++++ .../8-develop/3-component.md | 64 +++ .../8-develop/4-design.md | 247 +++++++++ .../8-develop/5-business-logic.md | 224 ++++++++ .../8-develop/_index.md | 37 ++ .../1-opentelemetry-collector/_index.md | 79 +++ .../1-agent/1-1-validation.md | 60 +++ .../1-agent/1-2-test-agent.md | 95 ++++ .../1-3-fileexporter/1-test-fileexporter.md | 188 +++++++ .../1-agent/1-3-fileexporter/_index.md | 97 ++++ .../1-4-metadata/1-4-1-test-metadata.md | 182 +++++++ .../1-agent/1-4-metadata/_index.md | 90 ++++ .../1-agent/_index.md | 107 ++++ .../2-gateway/2-1-start-gateway.md | 57 ++ .../2-gateway/2-2-configure-agent.md | 111 ++++ .../2-gateway/2-3-send-metrics.md | 77 +++ .../2-gateway/2-4-send-traces.md | 92 ++++ .../2-gateway/2-5-addendum.md | 89 ++++ .../2-gateway/_index.md | 116 +++++ .../3-filelog/3-1-configuration.md | 73 +++ .../3-filelog/3-2-test-filelog.md | 150 ++++++ .../3-filelog/_index.md | 66 +++ .../4-1-configuration.md | 91 ++++ .../4-2-test-environment.md | 33 ++ .../4-building-resilience/4-3-failure.md | 46 ++ .../4-building-resilience/4-4-recovery.md | 78 +++ .../4-building-resilience/_index.md | 36 ++ .../5-dropping-spans/5-1-configuration.md | 73 +++ .../5-dropping-spans/5-2-test-filter.md | 128 +++++ .../5-dropping-spans/_index.md | 30 ++ .../6-sensitive-data/6-1-configuration.md | 126 +++++ .../6-sensitive-data/6-2-test-delete-tag.md | 92 ++++ .../6-sensitive-data/6-3-test-redaction.md | 141 +++++ .../6-sensitive-data/_index.md | 31 ++ .../7-transform-data/7-1-configuration.md | 118 +++++ .../7-transform-data/7-2-setup.md | 32 ++ .../7-transform-data/7-3-test-transform.md | 129 +++++ .../7-transform-data/_index.md | 44 ++ .../8-routing-data/8-1-connector.md | 42 ++ .../8-routing-data/8-2-pipelines.md | 110 ++++ .../8-routing-data/8-3-test-routing.md | 78 +++ .../8-routing-data/_index.md | 28 + .../9-sum-count/9-1-count-test.md | 94 ++++ .../9-sum-count/9-2-sum.md | 158 ++++++ .../9-sum-count/9-3-sum-test.md | 67 +++ .../9-sum-count/_index.md | 191 +++++++ .../2-advanced-collector-old/99-end/_index.md | 7 + .../2-advanced-collector-old/_index.md | 38 ++ .../2-advanced-collector-old/prerequisites.md | 79 +++ .../1-agent-gateway/1-1-gateway.md | 61 +++ .../1-agent-gateway/1-2-send-metrics.md | 99 ++++ .../1-agent-gateway/1-3-send-traces.md | 96 ++++ .../1-agent-gateway/1-4-send-logs.md | 152 ++++++ .../1-agent-gateway/_index.md | 98 ++++ .../2-1-configuration.md | 100 ++++ .../2-2-test-environment.md | 32 ++ .../2-building-resilience/2-3-failure.md | 40 ++ .../2-building-resilience/2-4-recovery.md | 76 +++ .../2-building-resilience/_index.md | 19 + .../3-dropping-spans/3-1-configuration.md | 73 +++ .../3-dropping-spans/3-2-test-filter.md | 146 ++++++ .../3-dropping-spans/_index.md | 27 + .../4-sensitive-data/4-1-configuration.md | 120 +++++ .../4-sensitive-data/4-2-test-delete-tag.md | 92 ++++ .../4-sensitive-data/4-3-test-redaction.md | 140 +++++ .../4-sensitive-data/_index.md | 28 + .../5-transform-data/5-1-configuration.md | 113 ++++ .../5-transform-data/5-2-setup.md | 29 ++ .../5-transform-data/5-3-test-transform.md | 129 +++++ .../5-transform-data/_index.md | 39 ++ .../6-routing-data/6-1-connector.md | 40 ++ .../6-routing-data/6-2-pipelines.md | 107 ++++ .../6-routing-data/6-3-test-routing.md | 77 +++ .../6-routing-data/_index.md | 27 + .../7-sum-count/7-1-count-test.md | 93 ++++ .../7-sum-count/7-2-sum.md | 159 ++++++ .../7-sum-count/7-3-sum-test.md | 67 +++ .../7-sum-count/_index.md | 192 +++++++ .../2-advanced-collector/8-wrap-up/_index.md | 7 + .../2-advanced-collector/_index.md | 35 ++ .../2-advanced-collector/prerequisites.md | 175 +++++++ .../_index.md | 9 + .../7-dashboards-detectors/_index.md | 42 ++ .../dashboards/1-01-sample_data.md | 27 + .../dashboards/1-02-exploring_charts.md | 42 ++ .../dashboards/1-03-editing-chart.md | 45 ++ .../dashboards/1-04-saving-charts.md | 67 +++ .../dashboards/1-05-new-chart.md | 28 + .../dashboards/1-06-filtering.md | 37 ++ .../dashboards/1-07-timeshift.md | 57 ++ .../dashboards/1-08-signalflow.md | 54 ++ .../dashboards/1-09-adding-charts.md | 68 +++ .../dashboards/1-10-notes-and-layout.md | 107 ++++ .../dashboards/_index.md | 28 + .../detectors/_index.md | 115 ++++ .../detectors/muting.md | 58 +++ .../1-connect-to-instance.md | 40 ++ .../2-deploy-collector.md | 323 ++++++++++++ .../3-deploy-sample-app.md | 247 +++++++++ .../4-create-troubleshooting-metricset.md | 31 ++ .../5-troubleshoot-using-tag-spotlight.md | 92 ++++ .../6-summary.md | 25 + .../_index.md | 23 + .../ja/ninja-workshops/foundations/_index.md | 10 + .../1-workshop-setup/1-aws-setup.md | 30 ++ .../1-workshop-setup/10-cleanup.md | 49 ++ .../1-workshop-setup/2-openshift-prereqs.md | 155 ++++++ .../3-deploy-openshift-cluster.md | 88 ++++ .../1-workshop-setup/4-deploy-nvidia-nim.md | 329 ++++++++++++ .../1-workshop-setup/6-setup-users.md | 172 ++++++ .../7-install-otel-collector.md | 107 ++++ .../1-workshop-setup/8-deploy-vector-db.md | 79 +++ .../9-deploy-portworx-service.md | 50 ++ .../1-workshop-setup/_index.md | 17 + .../1-overview-of-workshop-environment.md | 57 ++ .../2-workshop/10-deploy-llm-app.md | 79 +++ .../2-workshop/11-review-traces.md | 39 ++ .../14-cisco-ai-pods/2-workshop/12-wrapup.md | 22 + .../2-connect-to-openshift-cluster.md | 84 +++ .../2-workshop/3-deploy-otel-collector.md | 146 ++++++ .../2-workshop/4-monitor-nvidia-components.md | 225 ++++++++ .../2-workshop/5-monitor-vector-db.md | 117 +++++ .../2-workshop/6-monitor-storage.md | 100 ++++ .../2-workshop/7-review-ai-pod-dashboards.md | 63 +++ .../2-workshop/8-review-llm-app.md | 112 ++++ .../2-workshop/9-instrument-llm-app.md | 78 +++ .../14-cisco-ai-pods/2-workshop/_index.md | 14 + .../infrastructure/14-cisco-ai-pods/_index.md | 31 ++ .../infrastructure/2-hpa/1-deploy-otel.md | 113 ++++ .../2-hpa/2-k8s-namespaces-dns.md | 41 ++ .../2-hpa/3-apache-otel-receiver.md | 105 ++++ .../infrastructure/2-hpa/4-deploy-apache.md | 94 ++++ .../infrastructure/2-hpa/5-fix-apache.md | 130 +++++ .../infrastructure/2-hpa/6-deploy-loadgen.md | 88 ++++ .../infrastructure/2-hpa/7-setup-hpa.md | 92 ++++ .../infrastructure/2-hpa/_index.md | 18 + .../2-hpa/kubernetes-navigator.md | 120 +++++ .../ninja-workshops/infrastructure/_index.md | 8 + .../16-obi-ebpf/1-workshop-overview/_index.md | 132 +++++ .../2-python-warmup/1-install-and-run.md | 90 ++++ .../2-python-warmup/2-instrument-with-obi.md | 97 ++++ .../2-python-warmup/3-verify-in-splunk.md | 35 ++ .../16-obi-ebpf/2-python-warmup/_index.md | 16 + .../1-configure-and-start.md | 72 +++ .../3-docker-before-obi/2-generate-traffic.md | 47 ++ .../3-docker-before-obi/3-check-splunk.md | 30 ++ .../16-obi-ebpf/3-docker-before-obi/_index.md | 14 + .../4-docker-obi-magic/1-add-obi-service.md | 80 +++ .../4-docker-obi-magic/2-understand-config.md | 45 ++ .../4-docker-obi-magic/3-verify-traces.md | 69 +++ .../16-obi-ebpf/4-docker-obi-magic/_index.md | 14 + .../5-kubernetes/1-build-and-load-images.md | 125 +++++ .../5-kubernetes/2-deploy-baseline.md | 145 ++++++ .../5-kubernetes/3-add-obi-daemonset.md | 87 ++++ .../5-kubernetes/4-how-this-scales.md | 76 +++ .../16-obi-ebpf/5-kubernetes/_index.md | 12 + .../16-obi-ebpf/6-wrap-up/_index.md | 75 +++ .../instrumentation/16-obi-ebpf/_index.md | 35 ++ .../1-real-browser-test/1-recording-a-test.md | 196 +++++++ .../2-create-real-browser-test.md | 20 + .../1-real-browser-test/3-import-json.md | 26 + .../4-edit-test-settings.md | 63 +++ .../5-advanced-settings.md | 27 + .../1-real-browser-test/6-edit-steps.md | 51 ++ .../7-view-test-results.md | 62 +++ .../1-real-browser-test/_index.md | 18 + .../2-api-test/1-global-varilables.md | 26 + .../2-api-test/2-create-new-check.md | 22 + .../2-api-test/3-authentication-request.md | 62 +++ .../2-api-test/4-search-request.md | 43 ++ .../2-api-test/5-view-results.md | 52 ++ .../2-api-test/_index.md | 29 ++ .../4-synthetics-scripting/_index.md | 38 ++ .../img/add-new-test.png | Bin 0 -> 403195 bytes .../img/add-payload-token.png | Bin 0 -> 163602 bytes .../img/add-request.png | Bin 0 -> 94701 bytes .../img/add-search-payload.png | Bin 0 -> 189748 bytes .../img/add-search-request.png | Bin 0 -> 166649 bytes .../img/advanced-settings.png | Bin 0 -> 83932 bytes .../img/api-test-result.png | Bin 0 -> 363252 bytes .../4-synthetics-scripting/img/drilldown.png | Bin 0 -> 416744 bytes .../4-synthetics-scripting/img/edit-steps.png | Bin 0 -> 119407 bytes .../img/end-recording.png | Bin 0 -> 71885 bytes .../img/export-button.png | Bin 0 -> 111634 bytes .../img/export-json.png | Bin 0 -> 128074 bytes .../img/global-locations.png | Bin 0 -> 62951 bytes .../img/global-variables.png | Bin 0 -> 346739 bytes .../img/import-complete.png | Bin 0 -> 170740 bytes .../img/import-json.png | Bin 0 -> 197871 bytes .../4-synthetics-scripting/img/import.png | Bin 0 -> 123821 bytes .../img/new-api-check.png | Bin 0 -> 104154 bytes .../4-synthetics-scripting/img/new-test.png | Bin 0 -> 120151 bytes .../img/open-recorder.png | Bin 0 -> 129266 bytes .../4-synthetics-scripting/img/recorder.png | Bin 0 -> 113884 bytes .../img/recording-name.png | Bin 0 -> 71011 bytes .../4-synthetics-scripting/img/save-json.png | Bin 0 -> 298898 bytes .../img/scatterplot.png | Bin 0 -> 73814 bytes .../4-synthetics-scripting/img/step-names.png | Bin 0 -> 132779 bytes .../6-lambda-kinesis/1-setup.md | 203 ++++++++ .../2-auto-instrumentation.md | 284 ++++++++++ .../6-lambda-kinesis/3-lambdas-in-splunk.md | 107 ++++ .../4-manual-instrumentation.md | 162 ++++++ .../6-lambda-kinesis/5-redeploy-lambdas.md | 149 ++++++ .../6-lambda-kinesis/6-updated-lambdas.md | 111 ++++ .../6-lambda-kinesis/7-summary.md | 11 + .../6-lambda-kinesis/_index.md | 18 + .../1-connect-to-instance.md | 19 + .../10-troubleshoot-collector.md | 313 +++++++++++ .../8-docker-k8s-otel/11-summary.md | 20 + .../8-docker-k8s-otel/2-deploy-collector.md | 164 ++++++ .../8-docker-k8s-otel/3-deploy-dotnet-app.md | 191 +++++++ .../4-instrument-app-with-otel.md | 186 +++++++ .../8-docker-k8s-otel/5-dockerize-app.md | 267 ++++++++++ .../6-add-instrumentation-to-dockerfile.md | 284 ++++++++++ .../7-install-collector-k8s.md | 195 +++++++ .../8-docker-k8s-otel/8-deploy-app-k8s.md | 419 +++++++++++++++ .../9-customize-collector-config.md | 318 +++++++++++ .../8-docker-k8s-otel/_index.md | 21 + .../ninja-workshops/instrumentation/_index.md | 9 + .../1-access-cloud-instances.md | 42 ++ .../1-getting-started/_index.md | 19 + .../2-ingest-processor-pipelines/_index.md | 32 ++ .../1-login-to-splunk.md | 38 ++ .../2-review-k8s-events.md | 36 ++ .../3-create-ingest-pipeline.md | 108 ++++ .../4-confirm-metrics.md | 25 + .../3-create-an-ingest-pipeline/_index.md | 24 + .../1-update-ingest-pipeline.md | 67 +++ .../2-create-dashboard.md | 179 +++++++ .../4-update-pipeline-and-visualize/_index.md | 13 + .../5-workshop-conclusion/_index.md | 23 + .../_index.md | 39 ++ .../1-access-cloud-instances.md | 17 + .../1-getting-started/_index.md | 52 ++ .../2-creating-basic-alerts/_index.md | 74 +++ .../1-creating-o11y-service.md | 47 ++ .../2-creating-appd-service.md | 47 ++ .../3-creating-services-in-itsi/_index.md | 19 + .../4-creating-alerts-in-itsi/_index.md | 48 ++ .../5-episodes-in-itsi/_index.md | 50 ++ .../6-detectors-to-itsi/_index.md | 55 ++ .../_index.md | 47 ++ .../ja/ninja-workshops/operations/_index.md | 9 + content/ja/resources/_index.md | 5 +- content/ja/resources/data-model/_index.md | 84 +++ content/ja/resources/local-hosting/_index.md | 17 + content/ja/resources/local-hosting/diab.md | 27 + .../ja/resources/local-hosting/multipass.md | 164 ++++++ .../ja/resources/local-hosting/orbstack.md | 53 ++ content/ja/resources/local-hosting/proxmox.md | 140 +++++ content/ja/resources/otel-tagging/_index.md | 118 +++++ content/ja/resources/splunk-arcade/_index.md | 59 +++ content/ja/scenarios/_index.md | 7 + .../debug-problems/profiling/_index.md | 29 ++ .../debug-problems/tagging/_index.md | 24 + ...-cisco-enterprise-networks-content-pack.md | 68 +++ .../1-overview/_index.md | 135 +++-- .../2-deployment/1_thousandeyes_agent.md | 83 +-- .../2-deployment/2_otelcollector.md | 16 +- .../2-deployment/3_application.md | 20 +- .../2-deployment/_index.md | 8 +- .../3-splunk-integration/_index.md | 79 +-- .../1_configure_instrumentation.md | 71 +-- .../2_apm_integration.md | 45 +- .../4-distributed-tracing/3_create_tests.md | 72 ++- .../4-distributed-tracing/4_tbd.md | 82 +-- .../4-distributed-tracing/5_tbd.md | 110 ++-- .../4-distributed-tracing/_index.md | 20 +- .../5-rum-thousandeyes/1_rum_in_draft.md | 60 +-- .../5-rum-thousandeyes/_index.md | 8 +- .../6-summary/1_tbd.md | 80 +-- .../6-summary/_index.md | 12 +- .../7-troubleshooting/_index.md | 182 +++---- .../thousandeyes-integration/8-api/_index.md | 14 +- content/ja/splunk4rookies/_index.md | 17 +- .../3-quick-tour/_index.md | 14 + .../7-wrap-up/_index.md | 16 + .../o11y-rookies-26/1-modules/1-apm/_index.md | 18 + .../1-modules/1-intro/1-login/_index.md | 24 + .../1-intro/2-online-boutique/_index.md | 44 ++ .../1-modules/1-intro/3-rum/1-rum-overview.md | 27 + .../1-modules/1-intro/3-rum/2-rum-app-view.md | 44 ++ .../1-intro/3-rum/3-tag-spotlight.md | 22 + .../1-intro/3-rum/4-user-sessions.md | 25 + .../1-modules/1-intro/3-rum/5-rum-to-apm.md | 18 + .../1-modules/1-intro/3-rum/_index.md | 27 + .../1-intro/4-apm/1-apm-service-map.md | 30 ++ .../1-intro/4-apm/2-apm-service-view.md | 21 + .../1-intro/4-apm/3-apm-tag-spotlight.md | 26 + .../1-intro/4-apm/4-apm-service-breakdown.md | 28 + .../1-intro/4-apm/5-apm-trace-analyzer.md | 29 ++ .../1-intro/4-apm/6-apm-waterfall.md | 27 + .../1-modules/1-intro/4-apm/7-apm-to-logs.md | 25 + .../1-modules/1-intro/4-apm/_index.md | 31 ++ .../1-intro/5-logs/1-introduction.md | 25 + .../1-intro/5-logs/2-log-filtering.md | 20 + .../1-modules/1-intro/5-logs/3-log-entry.md | 31 ++ .../1-modules/1-intro/5-logs/_index.md | 26 + .../6-synthetics/1-synthetics-dashboard.md | 23 + .../6-synthetics/2-synthetics-detail.md | 18 + .../6-synthetics/3-synthetics-to-apm.md | 22 + .../6-synthetics/4-synthetics-detector.md | 10 + .../1-intro/6-synthetics/5-create-detector.md | 24 + .../1-modules/1-intro/6-synthetics/_index.md | 26 + .../1-modules/1-intro/7-wrap-up/_index.md | 14 + .../1-modules/1-intro/_index.md | 27 + .../o11y-rookies-26/1-modules/2-im/_index.md | 18 + .../o11y-rookies-26/1-modules/3-dem/_index.md | 18 + .../1-modules/4-logs/1-introduction.md | 32 ++ .../4-logs/2-navigate-log-observer.md | 26 + .../4-logs/3-filtering-and-grouping.md | 58 +++ .../4-logs/4-timeline-and-patterns.md | 61 +++ .../1-modules/4-logs/5-root-cause.md | 54 ++ .../1-modules/4-logs/6-scenario-2-overview.md | 20 + .../4-logs/7-scenario-2-placeholder.md | 27 + .../1-modules/4-logs/_index.md | 28 + .../1-modules/5-db-mon/_index.md | 18 + .../1-modules/6-secure-app/_index.md | 18 + .../o11y-rookies-26/1-modules/7-ai/_index.md | 18 + .../o11y-rookies-26/1-modules/_index.md | 10 + .../o11y-rookies-26/11-login/_index.md | 24 + .../12-astronomy-shop/_index.md | 37 ++ .../o11y-rookies-26/2-wrap-up/_index.md | 16 + .../splunk4rookies/o11y-rookies-26/_index.md | 26 + .../1-login/_index.md | 24 + .../2-online-boutique/_index.md | 44 ++ .../3-rum/1-rum-overview.md | 27 + .../3-rum/2-rum-app-view.md | 44 ++ .../3-rum/3-tag-spotlight.md | 22 + .../3-rum/4-user-sessions.md | 25 + .../3-rum/5-rum-to-apm.md | 18 + .../observability-cloud-short/3-rum/_index.md | 27 + .../4-apm/1-apm-service-map.md | 30 ++ .../4-apm/2-apm-service-view.md | 21 + .../4-apm/3-apm-tag-spotlight.md | 26 + .../4-apm/4-apm-service-breakdown.md | 28 + .../4-apm/5-apm-trace-analyzer.md | 29 ++ .../4-apm/6-apm-waterfall.md | 27 + .../4-apm/7-apm-to-logs.md | 25 + .../observability-cloud-short/4-apm/_index.md | 31 ++ .../5-logs/2-log-filtering.md | 20 + .../5-logs/3-log-entry.md | 31 ++ .../5-logs/_index.md | 26 + .../6-synthetics/1-synthetics-dashboard.md | 23 + .../6-synthetics/2-synthetics-detail.md | 18 + .../6-synthetics/3-synthetics-to-apm.md | 22 + .../6-synthetics/5-create-detector.md | 24 + .../6-synthetics/_index.md | 26 + .../7-wrap-up/_index.md | 14 + .../observability-cloud-short/_index.md | 28 + .../observability-cloud/10-wrap-up/_index.md | 15 +- .../3-quick-tour/1-homepage/1-home-page.md | 52 +- .../3-quick-tour/1-homepage/_index.md | 34 +- .../3-quick-tour/2-rum-home/1-rum-home.md | 55 +- .../3-quick-tour/3-apm-home/1-apm-home.md | 48 +- .../1-log-observer-home.md | 60 +-- .../5-synthetics-home/1-synthetics-home.md | 39 +- .../1-infrastructure-home.md | 80 +-- .../3-quick-tour/_index.md | 17 +- .../30-im-exercise/1-im-exercise.md | 44 +- .../30-im-exercise/2-im-exercise.md | 48 +- .../30-im-exercise/3-im-exercise.md | 46 +- .../4-online-boutique/_index.md | 34 +- .../5-rum/1-rum-dashboard.md | 48 +- .../5-rum/2-tag-spotlight.md | 34 +- .../5-rum/3-session-replay.md | 26 +- .../5-rum/4-user-sessions.md | 29 +- .../6-apm/1-apm-explore.md | 26 +- .../6-apm/2-apm-service-view.md | 43 +- .../6-apm/3-apm-tag-spotlight.md | 39 +- .../6-apm/4-apm-service-breakdown.md | 33 +- .../6-apm/5-apm-trace-analyzer.md | 71 ++- .../6-apm/6-apm-waterfall.md | 44 +- .../7-log-observer/1-log-filtering.md | 32 +- .../7-log-observer/2-log-entry.md | 46 +- .../8-synthetics/1-synthetics-dashboard.md | 24 +- .../8-synthetics/2-synthetics-detail.md | 42 +- .../8-synthetics/3-synthetics-to-apm.md | 30 +- .../8-synthetics/4-synthetics-detector.md | 40 +- .../9-custom-dashboard/1-custom-dashboard.md | 44 +- .../9-custom-dashboard/2-add-chart.md | 34 +- .../9-custom-dashboard/3-custom-chart.md | 62 +-- .../observability-cloud/_index.md | 42 +- .../ja/unsupported-field-workshops/_index.md | 9 + content/ja/workshop-setup/2-splunk-show.md | 48 ++ 548 files changed, 38225 insertions(+), 1292 deletions(-) create mode 100644 content/ja/conf/1-advanced-collector/2-building-resilience/2-1-configuration.md create mode 100644 content/ja/conf/1-advanced-collector/3-dropping-spans/3-1-configuration.md create mode 100644 content/ja/conf/1-advanced-collector/4-sensitive-data/4-1-configuration.md create mode 100644 content/ja/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/1-introduction/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/2-related-content/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/3-autodetect/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/4-tag-spotlight/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/5-log-observer-ai/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/6-apm-assistant/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/7-wrap-up/_index.md create mode 100644 content/ja/ninja-workshops/ai/10-using-ai-in-o11y/_index.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/1-connect-to-instance.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/10-add-ai-defense-instrumentation.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/11-detect-security-risks.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/12-explore-other-ai-frameworks.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/13-wrapup.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/2-review-azure-ai-metrics.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/3-deploy-collector.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/_index.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/5-deploy-the-app.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/6-instrument-the-app.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/7-review-agent-trace-data.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/8-add-tool-calls.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/9-detect-quality-issue.md create mode 100644 content/ja/ninja-workshops/ai/18-agentic-ai/_index.md create mode 100644 content/ja/ninja-workshops/ai/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md create mode 100644 content/ja/ninja-workshops/apm/15-appd-workshop/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md create mode 100644 content/ja/ninja-workshops/apm/17-appd-ingest/_index.md create mode 100644 content/ja/ninja-workshops/apm/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md create mode 100644 content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md create mode 100644 content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md create mode 100644 content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md create mode 100644 content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md create mode 100644 content/ja/ninja-workshops/foundations/_index.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md create mode 100644 content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/_index.md create mode 100644 content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md create mode 100644 content/ja/ninja-workshops/infrastructure/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/7-view-test-results.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/1-global-varilables.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/2-create-new-check.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/3-authentication-request.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/4-search-request.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/5-view-results.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/2-api-test/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/add-new-test.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/add-payload-token.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/add-request.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/add-search-payload.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/add-search-request.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/advanced-settings.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/api-test-result.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/drilldown.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/edit-steps.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/end-recording.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/export-button.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/export-json.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/global-locations.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/global-variables.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/import-complete.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/import-json.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/import.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/new-api-check.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/new-test.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/open-recorder.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/recorder.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/recording-name.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/save-json.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/scatterplot.png create mode 100644 content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/img/step-names.png create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/1-setup.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/2-auto-instrumentation.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/3-lambdas-in-splunk.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/4-manual-instrumentation.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/5-redeploy-lambdas.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/6-updated-lambdas.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/7-summary.md create mode 100644 content/ja/ninja-workshops/instrumentation/6-lambda-kinesis/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/1-connect-to-instance.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/10-troubleshoot-collector.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/11-summary.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/2-deploy-collector.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/3-deploy-dotnet-app.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/4-instrument-app-with-otel.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/5-dockerize-app.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/6-add-instrumentation-to-dockerfile.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/7-install-collector-k8s.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/8-deploy-app-k8s.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/9-customize-collector-config.md create mode 100644 content/ja/ninja-workshops/instrumentation/8-docker-k8s-otel/_index.md create mode 100644 content/ja/ninja-workshops/instrumentation/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/1-getting-started/1-access-cloud-instances.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/1-getting-started/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/2-ingest-processor-pipelines/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/1-login-to-splunk.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/2-review-k8s-events.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/3-create-ingest-pipeline.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/4-confirm-metrics.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/1-update-ingest-pipeline.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/5-workshop-conclusion/_index.md create mode 100644 content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/1-getting-started/1-access-cloud-instances.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/1-getting-started/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/2-creating-basic-alerts/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/1-creating-o11y-service.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/2-creating-appd-service.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/4-creating-alerts-in-itsi/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/5-episodes-in-itsi/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/6-detectors-to-itsi/_index.md create mode 100644 content/ja/ninja-workshops/operations/12-alerting-monitoring-with-itsi/_index.md create mode 100644 content/ja/ninja-workshops/operations/_index.md create mode 100644 content/ja/resources/data-model/_index.md create mode 100644 content/ja/resources/local-hosting/_index.md create mode 100644 content/ja/resources/local-hosting/diab.md create mode 100644 content/ja/resources/local-hosting/multipass.md create mode 100644 content/ja/resources/local-hosting/orbstack.md create mode 100644 content/ja/resources/local-hosting/proxmox.md create mode 100644 content/ja/resources/otel-tagging/_index.md create mode 100644 content/ja/resources/splunk-arcade/_index.md create mode 100644 content/ja/scenarios/_index.md create mode 100644 content/ja/scenarios/debug-problems/profiling/_index.md create mode 100644 content/ja/scenarios/debug-problems/tagging/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md create mode 100644 content/ja/splunk4rookies/financial-services-observability-cloud/3-quick-tour/_index.md create mode 100644 content/ja/splunk4rookies/financial-services-observability-cloud/7-wrap-up/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-apm/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/1-login/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/2-online-boutique/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/1-rum-overview.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/2-rum-app-view.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/3-tag-spotlight.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/4-user-sessions.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/5-rum-to-apm.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/1-apm-service-map.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/2-apm-service-view.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/3-apm-tag-spotlight.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/4-apm-service-breakdown.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/5-apm-trace-analyzer.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/6-apm-waterfall.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/7-apm-to-logs.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/4-apm/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/5-logs/1-introduction.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/5-logs/2-log-filtering.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/5-logs/3-log-entry.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/5-logs/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/1-synthetics-dashboard.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/2-synthetics-detail.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/3-synthetics-to-apm.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/4-synthetics-detector.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/5-create-detector.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/6-synthetics/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/7-wrap-up/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/2-im/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/3-dem/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/1-introduction.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/2-navigate-log-observer.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/3-filtering-and-grouping.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/4-timeline-and-patterns.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/5-root-cause.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/6-scenario-2-overview.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/7-scenario-2-placeholder.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/4-logs/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/5-db-mon/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/6-secure-app/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/7-ai/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/1-modules/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/11-login/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/12-astronomy-shop/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/2-wrap-up/_index.md create mode 100644 content/ja/splunk4rookies/o11y-rookies-26/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/1-login/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/2-online-boutique/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/1-rum-overview.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/2-rum-app-view.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/3-tag-spotlight.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/4-user-sessions.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/5-rum-to-apm.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/3-rum/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/1-apm-service-map.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/2-apm-service-view.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/3-apm-tag-spotlight.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/4-apm-service-breakdown.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/5-apm-trace-analyzer.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/6-apm-waterfall.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/7-apm-to-logs.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/4-apm/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/5-logs/2-log-filtering.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/5-logs/3-log-entry.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/5-logs/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/6-synthetics/1-synthetics-dashboard.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/6-synthetics/2-synthetics-detail.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/6-synthetics/3-synthetics-to-apm.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/6-synthetics/5-create-detector.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/6-synthetics/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/7-wrap-up/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/_index.md create mode 100644 content/ja/unsupported-field-workshops/_index.md create mode 100644 content/ja/workshop-setup/2-splunk-show.md diff --git a/content/ja/_index.md b/content/ja/_index.md index 3936a2d6e7..0bfbaa6ea0 100644 --- a/content/ja/_index.md +++ b/content/ja/_index.md @@ -1,30 +1,36 @@ ---- -archetype: home -title: Splunk Observability Workshops -linkTitle: Splunk Observability Workshops -description: Splunk を䜿甚したオブザヌバビリティ゜リュヌションの構築方法をご玹介したす。 -weight: 1 -isCJKLanguage: true ---- - -## Splunk Observabilityワヌクショップぞようこそ - -Splunk Observability Cloudの監芖、分析、察応ツヌルを䜿甚しお、アプリケヌションずむンフラストラクチャをリアルタむムで把握するこずができたす。 - -このワヌクショップでは、メトリクス、トレヌス、ログを取り蟌み、監芖し、可芖化し、分析するためのクラス最高のオブザヌバビリティ可芳枬性プラットフォヌムに぀いお説明したす。 - -![gif](images/observability-hero-dashboard.gif) - -{{% notice title="OpenTelemetry" color="#4f62ad" icon="fab fa-wpexplorer" %}} -このワヌクショップで[OpenTelemetry](https://opentelemetry.io)をアプリケヌションやむンフラの分析に圹立぀テレメトリデヌタメトリクス、トレヌス、ログの蚈装、生成、収集、゚クスポヌトに䜿甚したす。 -{{% /notice %}} - -{{% notice title="GitHub" color="#4078c0" icon="fab fa-github" %}} -このドキュメントには、issueやpull requestで [貢献](https://github.com/splunk/observability-workshop) するこずができたす。より良いワヌクショップにするために、是非ご協力ください。 -{{% /notice %}} - -{{% notice title="Twitter" color="#1DA1F2" icon="fab fa-twitter" %}} -[Splunk](https://twitter.com/splunk)のTwitterチャンネルでは、アップデヌト情報や興味深い読み物を玹介しおいたす。 -{{% /notice %}} - -{{%children type="card" description="true" %}} ++++ +title = "Observability Workshops" +hero_title = "Observability *Workshops*." +description = "Splunkでオブザヌバビリティ゜リュヌションを構築する方法を孊びたしょう" +weight = "1" +noautocards = true + +[[cta]] +label = "Rookiesを芋る" +href = "/splunk4rookies/" +style = "primary" + +[[cta]] +label = "Ninjasを芋る" +href = "/ninja-workshops/" +style = "ghost" ++++ + +{{< lead >}} +Splunk Observability Cloudが提䟛するモニタリング、分析、レスポンスツヌルを掻甚しお、アプリケヌションやむンフラストラクチャの状況をリアルタむムで把握したしょう。 +これらのワヌクショップでは、メトリクス、トレヌス、ログの取り蟌み、モニタリング、可芖化、分析においお業界最高クラスのオブザヌバビリティプラットフォヌムをご玹介したす。 +{{< /lead>}} + +{{< divider >}} + +{{< cards >}} +{{< card title="リ゜ヌス" href="/resources/" hero-icon="book-text" >}} +Splunk Observability Cloudを最倧限に掻甚するためのリ゜ヌスです。 +{{< /card >}} +{{< card title="シナリオ" href="/scenarios/" hero-icon="rocket" >}} +Splunk Observability Cloudの䟡倀を実際に䜓隓できるガむド付きワヌクショップです。 +{{< /card >}} +{{< card title="Unsupported Field Workshops" href="/unsupported-field-workshops/" hero-icon="users" >}} +Unsupported Field Workshopsは、Splunk Observability Cloudを最倧限に掻甚するためのワヌクショップです。 +{{< /card >}} +{{% /cards %}} diff --git a/content/ja/browse/_index.md b/content/ja/browse/_index.md index 96b0038f49..dc8a611183 100644 --- a/content/ja/browse/_index.md +++ b/content/ja/browse/_index.md @@ -1,7 +1,7 @@ --- -title: Browse *Workshops* -linkTitle: Browse Workshops -description: Every workshop in one place. +title: ワヌクショップを*探す* +linkTitle: ワヌクショップを探す +description: すべおのワヌクショップを䞀箇所に集めたした。 layout: browse weight: 5 menu: diff --git a/content/ja/conf/1-advanced-collector/2-building-resilience/2-1-configuration.md b/content/ja/conf/1-advanced-collector/2-building-resilience/2-1-configuration.md new file mode 100644 index 0000000000..0574583e84 --- /dev/null +++ b/content/ja/conf/1-advanced-collector/2-building-resilience/2-1-configuration.md @@ -0,0 +1,100 @@ +--- +title: 2.1 File Storage Configuration +linkTitle: 2.1 Configuration +weight: 1 +--- + +この挔習では、`agent.yaml` ファむルの `extensions:` セクションを曎新したす。このセクションは OpenTelemetry の構成 YAML の䞀郚で、OpenTelemetry Collector の動䜜を拡匵たたは倉曎するオプションコンポヌネントを定矩したす。 + +これらのコンポヌネントはテレメトリヌデヌタを盎接凊理するわけではありたせんが、Collector の機胜を向䞊させるための有甚な機胜やサヌビスを提䟛したす。 + +{{% notice title="Exercise" style="green" icon="running" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりで `2-building-resilience` ディレクトリに移動し、`clear` コマンドを実行しおください。** + +ディレクトリ構造は以䞋のようになりたす: + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +**`agent.yaml` の曎新**: **Agent タヌミナル** りィンドりで、既存の `health_check` ゚クステンションの䞋に `file_storage` ゚クステンションを远加したす: + +```yaml + file_storage/checkpoint: # Extension Type/Name + directory: "./checkpoint-dir" # Define directory + create_directory: true # Create directory + timeout: 1s # Timeout for file operations + compaction: # Compaction settings + on_start: true # Start compaction at Collector startup + # Define compaction directory + directory: "./checkpoint-dir/tmp" + max_transaction_size: 65536 # Max. size limit before compaction occurs +``` + +**゚クスポヌタヌぞの `file_storage` の远加**: `otlphttp` ゚クスポヌタヌを倉曎しおリトラむおよびキュヌむング機構を構成し、障害が発生した堎合でもデヌタが保持され、再送されるようにしたす。`endpoint: "http://localhost:5318"` の䞋に以䞋を远加し、むンデントが `endpoint` ず䞀臎しおいるこずを確認しおください: + +```yaml + retry_on_failure: + enabled: true # Enable retry on failure + sending_queue: # + enabled: true # Enable sending queue + num_consumers: 10 # No. of consumers + queue_size: 10000 # Max. queue size + storage: file_storage/checkpoint # File storage extension +``` + +**`services` セクションの曎新**: 既存の `extensions:` セクションに `file_storage/checkpoint` ゚クステンションを远加したす。構成は以䞋のようになりたす: + +```yaml +service: + extensions: + - health_check + - file_storage/checkpoint # Enabled extensions for this collector +``` + +**`metrics` パむプラむンの曎新**: この挔習では、デバッグやログのノむズを枛らすために、Metric パむプラむンから `hostmetrics` レシヌバヌをコメントアりトしたす。同様に、構成は以䞋のようになりたす: + +```yaml + metrics: + receivers: + # - hostmetrics # Hostmetric reciever (cpu only) + - otlp +``` + +{{% /notice %}} + + diff --git a/content/ja/conf/1-advanced-collector/3-dropping-spans/3-1-configuration.md b/content/ja/conf/1-advanced-collector/3-dropping-spans/3-1-configuration.md new file mode 100644 index 0000000000..b87a29764f --- /dev/null +++ b/content/ja/conf/1-advanced-collector/3-dropping-spans/3-1-configuration.md @@ -0,0 +1,75 @@ +--- +title: 3.1 Configuration +linkTitle: 3.1 Configuration +weight: 1 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway terminal** りィンドりに切り替えお、`gateway.yaml` ファむルを開いおください。`processors` セクションを以䞋の蚭定で曎新したす。 + +1. **`filter` プロセッサヌを远加する**: + `/_healthz` ずいう名前のスパンを陀倖するように Gateway を蚭定したす。`error_mode: ignore` ディレクティブにより、フィルタリング䞭に発生した゚ラヌは無芖され、パむプラむンは問題なく動䜜し続けたす。`traces` セクションでフィルタリングルヌルを定矩し、`/_healthz` ずいう名前のスパンを陀倖察象ずしお指定したす。 + + ```yaml + filter/health: # Defines a filter processor + error_mode: ignore # Ignore errors + traces: # Filtering rules for traces + span: # Exclude spans named "/_healthz" + - 'name == "/_healthz"' + ``` + +2. **`filter` プロセッサヌを `traces` パむプラむンに远加する**: + `filter/health` プロセッサヌを `traces` パむプラむンに含めたす。最適なパフォヌマンスを埗るためには、フィルタヌをできるだけ早い段階、぀たり `memory_limiter` の盎埌、`batch` プロセッサヌの前に配眮しおください。蚭定は以䞋のようになりたす。 + + ```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - filter/health # Filters data based on rules + - resource/add_mode + - batch + exporters: + - debug + - file/traces + ``` + +この蚭定により、ヘルスチェック関連のスパン (`/_healthz`) がパむプラむンの早い段階でフィルタリングされ、テレメトリヌデヌタの䞍芁なノむズを削枛できたす。 + +{{% /notice %}} + + + + \ No newline at end of file diff --git a/content/ja/conf/1-advanced-collector/4-sensitive-data/4-1-configuration.md b/content/ja/conf/1-advanced-collector/4-sensitive-data/4-1-configuration.md new file mode 100644 index 0000000000..d3643a3e15 --- /dev/null +++ b/content/ja/conf/1-advanced-collector/4-sensitive-data/4-1-configuration.md @@ -0,0 +1,124 @@ +--- +title: 4.1 Configuration +linkTitle: 4.1 Configuration +weight: 1 +--- + +このステップでは、`agent.yaml` を倉曎しお `attributes` プロセッサヌず `redaction` プロセッサヌを远加したす。これらのプロセッサヌは、span 属性内の機密デヌタがログ出力や゚クスポヌトの前に適切に扱われるようにするのに圹立ちたす。 + +これたでに、コン゜ヌルに衚瀺された䞀郚の span 属性に個人情報や機密デヌタが含たれおいるこずに気づいた方もいるかもしれたせん。ここでは、こうした情報を効果的にフィルタリングしお秘匿化するために必芁なプロセッサヌを蚭定したす。 + +```text +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.account_password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + {"kind": "exporter", "data_type": "traces", "name": "debug"} +``` + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent タヌミナル** りィンドりに切り替えお、゚ディタヌで `agent.yaml` ファむルを開いおください。テレメトリヌデヌタのセキュリティずプラむバシヌを匷化するため、2぀のプロセッサヌを远加したす。 + +**1. `attributes` プロセッサヌを远加する**: [**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) を䜿甚するず、span 属性タグの倀を曎新、削陀、たたはハッシュ化するこずで倉曎できたす。これは、゚クスポヌト前に機密情報を難読化する際に特に圹立ちたす。 + +このステップでは、以䞋を実斜したす。 + +1. `user.phone_number` 属性を静的な倀 `("UNKNOWN NUMBER")` に **曎新** したす。 +2. `user.email` 属性を **ハッシュ化** しお、元のメヌルアドレスが露出しないようにしたす。 +3. `user.password` 属性を **削陀** しお、span から完党に取り陀きたす。 + +```yaml + attributes/update: + actions: # Actions + - key: user.phone_number # Target key + action: update # Update action + value: "UNKNOWN NUMBER" # New value + - key: user.email # Target key + action: hash # Hash the email value + - key: user.password # Target key + action: delete # Delete the password + ``` + +**2. `redaction` プロセッサヌを远加する**: [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) は、クレゞットカヌド番号やその他の個人を特定できる情報PIIなど、事前定矩されたパタヌンに基づいお span 属性内の機密デヌタを怜出しお秘匿化したす。 + +このステップでは、以䞋を実斜したす。 + +- `allow_all_keys: true` を蚭定しお、すべおの属性が凊理されるようにしたす`false` に蚭定するず、明瀺的に蚱可されたキヌのみが保持されたす。 + +- `blocked_values` に正芏衚珟を定矩しお、**Visa** および **MasterCard** のクレゞットカヌド番号を怜出しお秘匿化したす。 + +- `summary: debug` オプションは、デバッグ目的で秘匿化凊理に関する詳现情報をログに蚘録したす。 + +```yaml + redaction/redact: + allow_all_keys: true # If false, only allowed keys will be retained + blocked_values: # List of regex patterns to block + - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # Visa + - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # MasterCard + summary: debug # Show debug details about redaction +``` + +**`traces` パむプラむンを曎新する**: 䞡方のプロセッサヌを `traces` パむプラむンに統合したす。最初は redaction プロセッサヌをコメントアりトしおおくようにしおください埌の別の挔習で有効化したす。蚭定は次のようになりたす。 + +```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + #- redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp +``` + +{{% /notice %}} + + diff --git a/content/ja/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md b/content/ja/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md new file mode 100644 index 0000000000..785ed4026f --- /dev/null +++ b/content/ja/conf/1-advanced-collector/6-routing-data/6-2-pipelines.md @@ -0,0 +1,109 @@ +--- +title: 6.2 Configuring the Pipelines +linkTitle: 6.2 Pipeline Configuration +weight: 2 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**元の `traces` パむプラむンを曎新しおルヌティングを䜿甚したす**: + +1. `routing` を有効化するために、元の `traces` パむプラむンを曎新しお `routing` を唯䞀の exporter ずしお䜿甚するようにしたす。これにより、すべおのスパンデヌタが **Routing Connector** を経由しお評䟡され、その埌接続されたパむプラむンぞ送られたす。たた、processors は **すべお** 削陀し、空配列`[]`に眮き換えおください。これは `traces/route1-regular` ず `traces/route2-security` のパむプラむン偎で扱われるようになり、ルヌトごずにカスタム動䜜を実珟できるためです。`traces:` の蚭定は次のようになりたす: + + ```yaml + traces: # Traces pipeline + receivers: + - otlp # OTLP receiver + processors: [] # Processors for traces + exporters: + - routing + ``` + +**既存の `traces` パむプラむンの䞋に、`route1-regular` ず `route2-security` の䞡方の traces パむプラむンを远加したす**: + +1. **Route1-regular パむプラむンの蚭定**: このパむプラむンは、connector のルヌティングテヌブルで **どれにも䞀臎しない** すべおのスパンを凊理したす。 +このパむプラむンは receiver ずしお `routing` のみを䜿甚し、`connection` を通じお元の traces パむプラむンからデヌタを受け取るこずに泚目しおください。 + + ```yaml + traces/route1-regular: # Default pipeline for unmatched spans + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug Exporter + - file/traces/route1-regular # File Exporter for unmatched spans + ``` + +2. **route2-security パむプラむンの远加**: このパむプラむンは、ルヌティングルヌル `"[deployment.environment"] == "security-applications"` に䞀臎するすべおのスパンを凊理したす。このパむプラむンも receiver ずしお `routing` を䜿甚したす。`traces/route1-regular` の䞋にこのパむプラむンを远加しおください。 + + ```yaml + traces/route2-security: # Default pipeline for unmatched spans + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug exporter + - file/traces/route2-security # File exporter for unmatched spans + ``` + +{{% /notice %}} + + \ No newline at end of file diff --git a/content/ja/ninja-workshops/13-observing-business-journeys/_index.md b/content/ja/ninja-workshops/13-observing-business-journeys/_index.md index bbd2da3d78..97d83f3299 100644 --- a/content/ja/ninja-workshops/13-observing-business-journeys/_index.md +++ b/content/ja/ninja-workshops/13-observing-business-journeys/_index.md @@ -1,5 +1,5 @@ --- -title: ビゞネスゞャヌニヌの芳枬 +title: Observing Business Journeys linkTitle: Obs Biz Journey weight: 13 archetype: chapter @@ -8,6 +8,6 @@ description: TBD hidden: true --- -# ワヌクショップ: Biz Journey +## ワヌクショップ: Biz Journey ABC diff --git a/content/ja/ninja-workshops/_index.md b/content/ja/ninja-workshops/_index.md index 03da7aee00..5b2dc2a61c 100644 --- a/content/ja/ninja-workshops/_index.md +++ b/content/ja/ninja-workshops/_index.md @@ -1,8 +1,11 @@ --- -title: Splunk4Ninjas Workshops -menuPost: " " +title: Ninja Workshops +hero_title: Splunk4*Ninjas*. +layout: "hero" weight: 2 -description: The following workshops require Ninja skills, wax on, wax off. +description: Splunk Observability Cloudの基本操䜜にすでに慣れおいる方向けの、より深い内容のワヌクショップです。これらの䞊玚ワヌクショップでは、自動怜出auto-discovery、AI支揎によるトラブルシュヌティング、OpenTelemetryの内郚構造、むンゞェスト凊理に぀いお掘り䞋げたす。 +params: + images: + - images/s4n-featured.png --- -{{% children type="card" depth="1" description="true" %}} diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/1-introduction/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/1-introduction/_index.md new file mode 100644 index 0000000000..acd55e5991 --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/1-introduction/_index.md @@ -0,0 +1,57 @@ +--- +title: Splunk Observability Cloud における AI の抂芁 +linkTitle: 1. はじめに +weight: 1 +--- + +## 抂芁 + +人工知胜AIず機械孊習MLは、オブザヌバビリティぞの取り組み方を倉革し぀぀ありたす。手動でルヌルやしきい倀を䜜成したり、膚倧なデヌタを怜玢したりするのではなく、AI を掻甚するこずで次のこずが可胜になりたす。 + +- 孊習されたパタヌンに基づいお**異垞を自動的に怜出する** +- 問題を調査する際に**関連するコンテキストを衚瀺する** +- むンテリゞェントな盞関分析により**根本原因を迅速に特定する** +- ナヌザヌに圱響が及ぶ前に**将来の問題を予枬する** +- よりスマヌトでコンテキストに応じた通知により**アラヌトノむズを削枛する** + +## Splunk Observability Cloud の AI 機胜 + +Splunk Observability Cloud は、プラットフォヌム党䜓で AI ず ML を統合しおいたす。 + +### 1. Related Content + +珟圚衚瀺しおいる内容に基づいお関連するダッシュボヌド、Detector、リ゜ヌスを衚瀺するコンテキスト察応 AI で、耇雑な環境をより効率的にナビゲヌトできるようにしたす。 + +### 2. AutoDetect + +機械孊習を掻甚した Detector 䜜成機胜で、手動でのしきい倀蚭定なしに、環境固有のベヌスラむンを自動的に確立し、異垞を識別したす。 + +### 3. Tag Spotlight + +メタデヌタずタグ党䜓のパタヌンを調査しお、パフォヌマンス䜎䞋の原因を特定する AI 駆動の根本原因分析機胜です。 + +### 4. Log Observer AI + +ログにおける高床なパタヌン認識ず異垞怜出を提䟛し、自然蚀語機胜により耇雑なログデヌタの理解を支揎したす。 + +### 5. APM AI Assistant + +アプリケヌションパフォヌマンスのトラブルシュヌティングをむンテリゞェントにガむドし、トレヌスデヌタの理解ずボトルネックの特定を支揎したす。 + +### 6. Predictive Analytics + +ML モデルを䜿甚しお将来のトレンドやキャパシティニヌズを予枬する予枬機胜です。 + +## ワヌクショップの前提条件 + +このワヌクショップでは以䞋が必芁です。 + +- Splunk Observability Cloud 組織ぞのアクセストラむアルたたは本番環境 +- Splunk Observability Cloud のナビゲヌションに関する基本的な知識 +- オブザヌバビリティのコアコンセプトメトリクス、トレヌス、ログの理解 + +{{% notice title="泚意" style="info" %}} +このワヌクショップでは、Splunk Observability Cloud で利甚可胜なデモデヌタず実際の機胜を䜿甚したす。䞀郚の AI 機胜には特定の゚ンタむトルメントが必芁な堎合や、プレビュヌモヌドである堎合がありたす。 +{{% /notice %}} + +それでは、AI がオブザヌバビリティの実践をどのように匷化できるか、探っおいきたしょう diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/2-related-content/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/2-related-content/_index.md new file mode 100644 index 0000000000..40c1f03cca --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/2-related-content/_index.md @@ -0,0 +1,79 @@ +--- +title: Related Content +linkTitle: 2. Related Content +weight: 2 +--- + +## Related Content ずは + +Related Content は Splunk Observability Cloud に搭茉された AI 機胜で、オブザヌバビリティデヌタを操䜜しおいる最䞭に、文脈に関連する情報を自動的に提瀺したす。関連するダッシュボヌド、ディテクタヌ、トレヌスを手䜜業で怜玢する代わりに、AI ゚ンゞンが珟圚のコンテキストを分析し、最も関連性の高いリ゜ヌスを提瀺したす。 + +## Related Content の仕組み + +AI ゚ンゞンは耇数の芁玠を考慮したす。 + +- **珟圚の閲芧コンテキスト**: 確認䞭のサヌビス、ホスト、メトリクス +- **メタデヌタずタグ**: 共通のディメンションずプロパティ +- **ナヌザヌの行動パタヌン**: 同様のコンテキストで他のナヌザヌが通垞閲芧する内容 +- **時間的な関係性**: リ゜ヌス間の時間ベヌスの盞関 +- **意味的な関係性**: 名前付き゚ンティティずその論理的な接続 + +## 䞻なメリット + +1. **より速いナビゲヌション**: 手動怜玢なしで関連リ゜ヌスに盎接ゞャンプできたす +2. **隠れた関係性の発芋**: 存圚を知らなかった接続を芋぀けられたす +3. **調査の効率化**: むンシデント察応時に AI が提案する経路をたどれたす +4. **ナレッゞの発芋**: 他のチヌムが䜜成したダッシュボヌドやディテクタヌを把握できたす + +## Related Content が衚瀺される堎所 + +Related Content はプラットフォヌム内の耇数の堎所に衚瀺されたす。 + +- **ダッシュボヌドペヌゞ**: 関連するダッシュボヌドずディテクタヌ +- **APM サヌビスペヌゞ**: 関連するトレヌス、ログ、むンフラストラクチャヌ +- **ディテクタヌペヌゞ**: 関連するダッシュボヌドずその他のディテクタヌ +- **チャヌトペヌゞ**: 関連する可芖化やメトリクス + +## ハンズオン挔習 + +{{% notice title="挔習" style="primary" icon="tasks" %}} + +### APM で Related Content を確認する + +1. Splunk Observability Cloud 組織で **APM** → **Services** に移動したす +2. 䞀芧から任意のサヌビスを遞択したす +3. **Related Content** セクションを探したす通垞は右サむドバヌたたはペヌゞ䞋郚にありたす +4. 提案されるリ゜ヌスの皮類を確認したす。 + - 関連するダッシュボヌド + - 関連するディテクタヌ + - 接続されたサヌビス + - むンフラストラクチャヌコンポヌネント +5. 提案された項目のいずれかをクリックし、コンテキストがどう倉化するかを芳察したす +6. 新しいビュヌで Related Content を確認し、珟圚のコンテキストに合わせおどう適応するかを確認したす + +{{% /notice %}} + +## 掚奚内容を理解する + +Related Content の提案を芋る際は、次の点を考慮しおください。 + +- **なぜ関連しおいるのか**: 共通のタグ、呜名パタヌン、䟝存関係に着目したす +- **関係性の匷さ**: 䞊䜍の項目ほど通垞は関連性が匷くなりたす +- **カバレッゞ**: 期埅したコンテンツが衚瀺されない堎合、タグ付けやメタデヌタの改善が必芁かもしれたせん + +## ベストプラクティス + +Related Content を最倧限掻甚するためのポむントです。 + +1. サヌビス、ダッシュボヌド、ディテクタヌで **䞀貫した呜名芏則** を䜿甚したす +2. リ゜ヌスに **包括的なタグ** を適甚したす +3. **カスタムプロパティ** を掻甚しお意味的な関係性を䜜成したす +4. 調査䞭は **提案に埓っお** 新たなむンサむトを発芋したす + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +䞀貫したタグ付けず呜名で Splunk Observability Cloud を䜿い続けるほど、Related Content の AI は関連情報をより的確に提瀺できるようになりたす。 +{{% /notice %}} + +## 次のステップ + +Related Content を理解したずころで、次は AutoDetect が ML を䜿っおどのようにむンテリゞェントなディテクタヌを自動䜜成するかを芋おいきたしょう。 diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/3-autodetect/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/3-autodetect/_index.md new file mode 100644 index 0000000000..17fb4cd89a --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/3-autodetect/_index.md @@ -0,0 +1,130 @@ +--- +title: AutoDetect ず ML 駆動の異垞怜知 +linkTitle: 3. AutoDetect +weight: 3 +--- + +## AutoDetect ずは + +AutoDetect は機械孊習を掻甚した機胜で、手動でしきい倀を蚭定するこずなく、メトリクスに察しおむンテリゞェントな Detector を自動的に䜜成したす。静的なしきい倀を圓おずっぜうで蚭定する代わりに、AutoDetect はメトリクスの正垞な振る舞いパタヌンを孊習し、逞脱が発生した際にアラヌトを発したす。 + +## AutoDetect の仕組み + +AutoDetect は以䞋の ML 技術を䜿甚しおいたす。 + +1. **ベヌスラむン孊習**: 過去のデヌタを分析しお正垞なパタヌンを把握したす +2. **季節性の認識**: 日次、週次、月次のパタヌンを認識したす +3. **動的なしきい倀**: メトリクスの倉動性に基づいお感床を調敎したす +4. **コンテキストを螏たえた異垞怜知**: 耇数のシグナルを組み合わせお、より賢いアラヌトを実珟したす + +## ML を掻甚した Detector の皮類 + +### Sudden Change Detection + +メトリクスが孊習したパタヌンを超えお急激にスパむクしたり䜎䞋したりした際にアラヌトを発したす。 + +### Historical Anomaly Detection + +時間垯や曜日のパタヌンを考慮しながら、珟圚の倀を過去の暙準倀ず比范したす。 + +### Resource Detectors + +䞀般的なむンフラストラクチャリ゜ヌスCPU、メモリ、ディスク向けにあらかじめ蚭定された ML Detector です。 + +## ハンズオン: AutoDetect Detector を䜜成する + +{{% notice title="挔習" style="primary" icon="tasks" %}} + +### Step 1: Detector 䜜成画面に移動する + +1. **Alerts & Detectors** → **Detectors** に移動したす +2. **New Detector** をクリックしたす +3. **AutoDetect** たたは **From Template** を遞択したす + +### Step 2: メトリクスを遞択する + +1. 安定したトラフィックのあるメトリクス䟋: `demo.trans.latency` や `cpu.utilization`を遞びたす +2. 必芁なフィルタヌenvironment、service などを远加したす +3. デヌタが流れおいるこずを確認するためチャヌトを確認したす + +### Step 3: ML 蚭定を構成する + +1. **Sudden Change** たたは **Historical Anomaly** モヌドを遞択したす +2. 感床を調敎したす。 + - **Low**: アラヌト数は少なく、倧きな逞脱のみ怜出したす + - **Medium**: バランスの取れたアプロヌチ掚奚 + - **High**: より高感床で、わずかな倉化も捉えたす +3. 芳枬りィンドりどれだけの過去デヌタを考慮するかを蚭定したす + +### Step 4: アラヌト蚭定を構成する + +1. アラヌトの重芁床Critical、Warning、Infoを蚭定したす +2. 通知の受信者を蚭定したす +3. アラヌトメッセヌゞをカスタマむズしたす +4. 内容を確認しお Detector を有効化したす + +{{% /notice %}} + +## ML Detector の挙動を理解する + +### 孊習期間 + +AutoDetect Detector はベヌスラむンを確立するために時間を必芁ずしたす。 + +- **最小**: 24 時間分のデヌタ +- **掚奚**: 安定したベヌスラむンのために 1〜2 週間 +- **季節性パタヌン**: 週次パタヌンには 4 週間以䞊 + +### 感床のチュヌニング + +感床蚭定は、Detector がどの皋床積極的に怜知を行うかを制埡したす。 + +```text +Low Sensitivity → False Positive は少ないが、わずかな問題を芋逃す可胜性あり +Medium Sensitivity → バランス型デフォルト +High Sensitivity → より倚くの異垞を怜出するが、ノむズも増える可胜性あり +``` + +## ベストプラクティス + +1. **Medium Sensitivity から始める**: アラヌト量に応じお調敎したす +2. **適切なメトリクスを䜿甚する**: AutoDetect は以䞋のようなメトリクスで最も効果を発揮したす。 + - 明確なパタヌンを持぀メトリクスレむテンシヌ、リク゚ストレヌト + - 安定しお継続的なデヌタストリヌム + - 十分な過去デヌタ +3. **適切なディメンションでグルヌプ化する**: タグを䜿っおフォヌカスされた Detector を䜜成したす +4. **孊習に時間を䞎える**: 最初の 48 時間で有効性を刀断しないでください +5. **芋盎しずチュヌニング**: トリガヌされたアラヌトを定期的に確認し、感床を調敎したす + +## AutoDetect ず静的しきい倀の䜿い分け + +| AutoDetect を䜿うべき堎合 | 静的しきい倀を䜿うべき堎合 | +|---------------------------|---------------------------| +| メトリクスに自然なばら぀きがある | 既知の固定された制限がある | +| パタヌンが時間ずずもに倉化する | 芏制や契玄䞊の芁件がある | +| トラフィックに季節性や呚期性がある | 単玔な二倀条件up/down | +| 「適切な」しきい倀が分からない | しきい倀が十分に確立されおいる | + +## AutoDetect のパフォヌマンスをモニタリングする + +ML Detector を䜜成した埌は、以䞋を行いたす。 + +1. **アラヌト履歎を確認する**: False Positive / False Negative をチェックしたす +2. **感床を調敎する**: アラヌトの品質に基づいおファむンチュヌニングしたす +3. **ベヌスラむンを曎新する**: ML モデルは倉化に自動的に適応したす +4. **埓来の Detector ず比范する**: ML がより早く問題を捉えるかを確認したす + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +AutoDetect は、ナヌザヌトラフィック、トランザクション量、API リク゚ストレヌトなど、時間垯や曜日によっお倉動するメトリクスに特に効果的です。 +{{% /notice %}} + +## よくある萜ずし穎 + +- **デヌタ䞍足**: パタヌンを孊習するのに十分な履歎が必芁です +- **ディメンションが倚すぎる**: 倚すぎるタグで分割するず ML モデルが垌薄になりたす +- **䞍安定なメトリクス**: 非垞に䞍芏則なメトリクスはノむズの倚いアラヌトを生む可胜性がありたす +- **最近のデプロむ**: 新しいサヌビスにはベヌスラむンデヌタがありたせん + +## 次のステップ + +AutoDetect に぀いお理解できたずころで、次は AI 駆動の根本原因分析を行う Tag Spotlight を芋おいきたしょう。 diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/4-tag-spotlight/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/4-tag-spotlight/_index.md new file mode 100644 index 0000000000..a98afc7214 --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/4-tag-spotlight/_index.md @@ -0,0 +1,204 @@ +--- +title: Tag Spotlight - AIによる根本原因分析 +linkTitle: 4. Tag Spotlight +weight: 4 +--- + +## Tag Spotlightずは + +Tag Spotlightは、タグやメタデヌタ党䜓のパタヌンを自動的に分析するこずで、パフォヌマンス問題の根本原因を玠早く特定できるAI駆動の分析機胜です。䜕癟ものタグの組み合わせを手動でフィルタリングする代わりに、Tag Spotlightは機械孊習を䜿甚しお、パフォヌマンス䜎䞋ず最も匷く盞関するタグ倀を浮き圫りにしたす。 + +## Tag Spotlightが解決する問題 + +次のようなサヌビスを想像しおください。 + +- 10皮類のリヌゞョン +- リヌゞョンごずに5぀のアベむラビリティゟヌン +- 20皮類のサヌビス゚ンドポむント +- 3぀のデプロむバヌゞョン + +これは手動でチェックするには3,000通りもの組み合わせになる可胜性がありたす。Tag Spotlightはすべおの組み合わせを自動的に分析し、問題のあるものを浮き圫りにしたす。 + +## Tag Spotlightの仕組み + +Tag Spotlightは耇数の分析手法を䜿甚したす。 + +1. **統蚈分析**: すべおのタグ倀にわたるパフォヌマンスを比范 +2. **パタヌン認識**: 倚次元デヌタ内の異垞なパタヌンを特定 +3. **寄䞎床分析**: 問題に最も寄䞎しおいるタグを算出 +4. **盞関スコアリング**: 問題ぞの関連性によっおタグをランク付け + +## Tag Spotlightぞのアクセス + +Tag Spotlightは䞻に2぀の堎所で利甚できたす。 + +### APMサヌビスマップ内 + +1. **APM** → **Services** に移動したす +2. 問題が発生しおいるサヌビスを遞択したす +3. トラブルシュヌティングパネル内の **Tag Spotlight** をクリックしたす + +### Troubleshooting MetricSets内 + +1. Troubleshooting MetricSet (TMS) を䜜成たたはアクセスしたす +2. Tag SpotlightはTMSの分析ビュヌに組み蟌たれおいたす + +## ハンズオン挔習: Tag Spotlightを䜿っおみる + +{{% notice title="挔習" style="primary" icon="tasks" %}} + +### Step 1: APMでTag Spotlightにアクセス + +1. **APM** → **Services** に移動したす +2. 耇数のタグを持぀サヌビス䟋: 異なるリヌゞョン、バヌゞョン、゚ンドポむントを遞択したす +3. **Tag Spotlight** たたは **Troubleshooting** セクションを探したす + +### Step 2: 結果を分析 + +Tag Spotlightは以䞋を衚瀺したす。 + +- パフォヌマンス問題ぞの **寄䞎床でランク付けされたタグ** +- タグ倀ごずのパフォヌマンスを瀺す **比范チャヌト** +- 各タグの **寄䞎床パヌセンテヌゞ** +- **統蚈的有意性** の指暙 + +### Step 3: 結果を解釈 + +以䞋に泚目しおください。 + +- **寄䞎床の高いタグ**: 䞊䜍のタグが最も圱響が倧きい +- **倖れ倀**: 異なる挙動を瀺す特定のタグ倀 +- **時間盞関**: 乖離が始たったのはい぀か + +### Step 4: ドリルダりン + +1. ハむラむトされたタグ倀をクリックしおビュヌをフィルタリングしたす +2. そのタグに関連する具䜓的なトレヌスやメトリクスを調べたす +3. パフォヌマンスが良奜なタグ倀ず比范したす +4. 根本原因コヌド、むンフラストラクチャ、蚭定を特定したす + +{{% /notice %}} + +## Tag Spotlightの結果を理解する + +### 寄䞎床スコア + +各タグがパフォヌマンス問題のどの皋床の割合を占めおいるかを瀺したす。 + +```text +Region: us-west-2 → 78% contribution +Version: v2.3.1 → 45% contribution +Endpoint: /checkout → 23% contribution +``` + +パヌセンテヌゞが高いほど、問題ずの盞関が匷いこずを瀺したす。 + +### 統蚈的有意性 + +Tag Spotlightは以䞋も考慮したす。 + +- **サンプルサむズ**: 十分なデヌタポむントがあるか +- **分散**: パタヌンの䞀貫性はどうか +- **ベヌスラむン比范**: 通垞時ず比べおどうか + +## 実際のナヌスケヌス + +### ナヌスケヌス 1: リヌゞョンのパフォヌマンス䜎䞋 + +**症状**: 党䜓のレむテンシが300ms増加 + +**Tag Spotlightが明らかにした内容**: + +- `aws_region: eu-central-1` → 92% 寄䞎 +- 他のリヌゞョンは正垞に動䜜 + +**根本原因**: EUリヌゞョンでのデヌタベヌスレプリケヌション遅延 + +### ナヌスケヌス 2: バヌゞョンロヌルアりトの問題 + +**症状**: デプロむ埌に゚ラヌ率が急増 + +**Tag Spotlightが明らかにした内容**: + +- `version: v3.0.1` → 85% 寄䞎 +- `endpoint: /api/search` → 67% 寄䞎 + +**根本原因**: 新しい怜玢゚ンドポむントがメモリリヌクを匕き起こしおいた + +### ナヌスケヌス 3: 顧客セグメントぞの圱響 + +**症状**: チェックアりトのレむテンシが増加 + +**Tag Spotlightが明らかにした内容**: + +- `tenant: enterprise-tier` → 71% 寄䞎 +- `payment_method: invoice` → 58% 寄䞎 + +**根本原因**: 新しい請求怜蚌凊理が゚ンタヌプラむズ向け請求曞発行を遅延させおいた + +## Tag Spotlightのベストプラクティス + +### 1. 充実したタグ付けを行う + +Tag Spotlightの粟床はタグの質に䟝存したす。以䞋を含めたしょう。 + +- **むンフラストラクチャタグ**: リヌゞョン、AZ、クラスタヌ、ノヌド +- **アプリケヌションタグ**: バヌゞョン、環境、フィヌチャヌフラグ +- **ビゞネスタグ**: テナント、顧客ティア、補品ラむン +- **カスタムディメンション**: ドメむンに関連するもの党般 + +### 2. 䞀貫したタグ名を䜿甚する + +- サヌビス間で暙準的な呜名芏則を䜿甚する +- 同矩語を避ける䟋: `region` ず `aws_region` を混圚させない +- タグ付け戊略を文曞化する + +### 3. 他のツヌルず組み合わせる + +Tag Spotlightを以䞋ず䜵甚したしょう。 + +- **APMトレヌス**: 実際のトレヌスデヌタで結果を怜蚌 +- **メトリクス**: 時系列デヌタでパタヌンを確認 +- **ログ**: 特定したタグに関する゚ラヌメッセヌゞを怜玢 + +### 4. Troubleshooting MetricSetsを䜜成する + +重芁なサヌビスに぀いおは、以䞋を含むTroubleshooting MetricSetsを事前に蚭定しおおきたしょう。 + +- 䞻芁なパフォヌマンス指暙レむテンシ、゚ラヌ率、スルヌプット +- 重芁なディメンションリヌゞョン、バヌゞョン、゚ンドポむント +- 適切なベヌスラむン比范期間 + +## Troubleshooting MetricSets (TMS) + +TMSはTag Spotlight甚に蚭蚈されたカスタムメトリクス集蚈です。 + +### TMSの䜜成 + +1. **APM** → **Troubleshooting MetricSets** に移動したす +2. **Create Troubleshooting MetricSet** をクリックしたす +3. サヌビスずメトリクスを遞択したす +4. 分析するディメンションを遞択したす +5. 保存しお有効化したす + +### TMSを䜜成すべきタむミング + +- **重芁なサヌビス**: 厳栌なSLAを持぀サヌビス +- **耇雑なアヌキテクチャ**: 倚くのディメンションを持぀サヌビス +- **再発する問題**: パフォヌマンス倉動が頻繁に起こるサヌビス +- **マルチテナントシステム**: 顧客ぞの圱響が異なる堎合 + +## 制限事項ず考慮事項 + +- **十分なデヌタが必芁**: タグ倀ごずに十分なサンプル数が必芁 +- **盞関 ≠ 因果**: Tag Spotlightは盞関を瀺す。根本原因は怜蚌が必芁 +- **タグのカヌディナリティ**: 非垞に高カヌディナリティのタグ䟋: ナヌザヌIDは有甚でない堎合がある +- **時間枠が重芁**: 適切な比范期間を遞択する + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +Tag Spotlightは、分析察象ずなる明確なパフォヌマンス䜎䞋期間がある堎合に最も効果を発揮したす。正確な結果を埗るために、ベヌスラむンず比范りィンドりを慎重に定矩しおください。 +{{% /notice %}} + +## 次のステップ + +Tag Spotlightを理解したずころで、Log ObserverにおけるAI機胜を芋おいきたしょう。 diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/5-log-observer-ai/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/5-log-observer-ai/_index.md new file mode 100644 index 0000000000..82c229c92e --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/5-log-observer-ai/_index.md @@ -0,0 +1,255 @@ +--- +title: AI を掻甚したログ分析 +linkTitle: 5. Log Observer AI +weight: 5 +--- + +## Log Observer の AI 機胜 + +Splunk Observability Cloud の Log Observer には、倧量のログデヌタを理解するのに圹立぀ AI 搭茉機胜がいく぀か含たれおいたす。 + +- **Pattern Detection**: ログ内の共通パタヌンを自動的に識別したす +- **Anomaly Highlighting**: 異垞なログ゚ントリやパタヌンを浮き圫りにしたす +- **Log Clustering**: 類䌌のログメッセヌゞをグルヌプ化したす +- **Intelligent Filtering**: コンテキストに基づき AI が提案するフィルタヌ +- **Natural Language Queries**: 平易な蚀葉でログをク゚リできたす (利甚可胜な堎合) + +## Pattern Detection + +### Log Pattern Detection ずは + +個々のログ行を衚瀺する代わりに、Pattern Detection は構造ごずにログをグルヌプ化し、以䞋を容易にしたす。 + +- 頻出パタヌンず垌少パタヌンの識別 +- 新しいパタヌンや異垞なログパタヌンの発芋 +- 異垞゚ントリぞの集䞭 +- 反埩的なログによるノむズの削枛 + +### 仕組み + +AI ゚ンゞンは以䞋を実行したす。 + +1. ログメッセヌゞの構造を分析 +2. 可倉郚分 (ID、タむムスタンプ、倀) を識別 +3. パタヌンテンプレヌトを䜜成 +4. テンプレヌトごずにログをグルヌプ化 +5. パタヌンの頻床ず倉化を远跡 + +## ハンズオン挔習: ログパタヌンの探玢 + +{{% notice title="挔習" style="primary" icon="tasks" %}} + +### Step 1: Log Observer にアクセス + +1. **Log Observer** に移動したす +2. アクティブなログデヌタがある時間範囲を遞択したす +3. 倚様なログを持぀サヌビスたたはむンデックスを遞びたす + +### Step 2: Pattern ビュヌを有効化 + +1. **Patterns** たたは **Pattern Analysis** ビュヌを探したす +2. 個別ログビュヌからパタヌンビュヌに切り替えたす +3. ログがどのようにクラスタリングされおいるかを芳察したす + +### Step 3: パタヌンの分析 + +パタヌンリストを確認したす。 + +- **High-frequency patterns**: 通垞の想定どおりのログ +- **New patterns**: 最近出珟したもの (朜圚的な問題) +- **Rare patterns**: 頻床が䜎く、調査する䟡倀のあるもの +- **Error patterns**: 構造化された゚ラヌメッセヌゞ + +### Step 4: 異垞の調査 + +1. 垌少たたは新しいパタヌンをクリックしたす +2. そのパタヌンに含たれるサンプルログを衚瀺したす +3. ベヌスラむン/通垞パタヌンず比范したす +4. 問題を瀺しおいるか刀断したす + +{{% /notice %}} + +## ログ異垞怜知 + +### 怜知される異垞の皮類 + +1. **Frequency Anomalies**: ログ量の急増/急枛 +2. **Content Anomalies**: 異垞なフィヌルド倀やメッセヌゞ内容 +3. **Pattern Anomalies**: ベヌスラむンに存圚しない新しいパタヌン +4. **Timing Anomalies**: 通垞ずは異なる時間に出珟するログ + +### 異垞怜知の蚭定 + +ML を掻甚したログベヌスの Detector をセットアップしたす。 + +1. **Alerts & Detectors** に移動したす +2. Log Observer から新しい Detector を䜜成したす +3. **Anomaly Detection** モヌドを遞択したす +4. 以䞋を蚭定したす。 + - ベヌスラむン期間 + - 感床レベル + - アラヌト条件 + - 通知チャネル + +## むンテリゞェントなログフィルタリング + +### AI が提案するフィルタヌ + +調査を進める䞭で、Log Observer は以䞋を提案するこずがありたす。 + +- **Related fields**: フィルタヌに䜿う䟡倀のあるタグや属性 +- **Common values**: 頻繁に出珟するフィヌルド倀 +- **Anomalous values**: 泚目に倀する異垞なフィヌルド倀 +- **Correlated attributes**: 共に出珟するこずが倚いフィヌルド + +### 提案フィルタヌの利甚 + +1. UI 䞊のフィルタヌ提案を探したす +2. クリックしお提案フィルタヌを適甚したす +3. 結果に基づいお絞り蟌みたす +4. 有甚なフィルタヌの組み合わせを保存したす + +## APM ずむンフラストラクチャずのログ盞関 + +### 自動的なコンテキストリンク + +AI は以䞋にログを接続するのに圹立ちたす。 + +- **Traces**: ログ゚ントリを分散トレヌスにリンク +- **Services**: ログを APM サヌビスに関連付け +- **Infrastructure**: ホスト、コンテナ、Pod に接続 +- **Metrics**: ログパタヌンずメトリクスの倉化を盞関 + +### AI のパンくずを蟿る + +調査䞭は以䞋を実行したす。 + +1. ログ゚ントリやパタヌンから始めたす +2. **Related Content** の提案を探したす +3. 盞関するトレヌス、メトリクス、むンフラストラクチャにゞャンプしたす +4. Tag Spotlight を䜿甚しお問題を絞り蟌みたす +5. ログに戻っお結果を怜蚌したす + +## ログの芁玄ずむンサむト + +### Key Insights パネル + +AI が生成するむンサむトには以䞋が含たれる堎合がありたす。 + +- **Error rate summaries**: ゚ラヌの皮類別にグルヌプ化 +- **Service health**: ログの重倧床に基づく +- **Trend analysis**: ログパタヌンの経時的倉化 +- **Comparative analysis**: 珟圚察ベヌスラむン期間 + +### むンサむトの䟋 + +```text +⚠ Error rate increased 340% in the last hour + → Top error: "Database connection timeout" (1,247 occurrences) + → Affected services: checkout-service, payment-service + → Started at: 14:23 UTC + +📊 New log pattern detected + → "WARN: Cache miss for key {key}" appeared 892 times + → First seen: 14:25 UTC + → May indicate cache invalidation issue +``` + +## AI を掻甚したログ分析のベストプラクティス + +### 1. ログを構造化する + +構造化ログを䜿甚しお AI を支揎したす。 + +```json +{ + "timestamp": "2024-01-15T14:23:45Z", + "level": "ERROR", + "service": "checkout-service", + "message": "Payment processing failed", + "error_code": "PAYMENT_TIMEOUT", + "transaction_id": "txn_123456", + "customer_tier": "enterprise" +} +``` + +### 2. 䞀貫したフィヌルド名を䜿甚する + +- サヌビス間でフィヌルド呜名を暙準化したす +- 共通の分類䜓系を䜿甚したす (䟋: `serviceName` や `service_id` ではなく `service.name`) +- すべおのログに必須コンテキストを含めたす + +### 3. 適切なログレベルを蚭定する + +- **DEBUG**: 詳现な蚺断情報 (開発甚) +- **INFO**: 䞀般的な情報メッセヌゞ +- **WARN**: 朜圚的に有害な状況 +- **ERROR**: アプリの継続を蚱す可胜性のある゚ラヌむベント +- **FATAL**: 早期終了を匕き起こす重倧な゚ラヌ + +### 4. ログサンプリングを掻甚する + +倧量のログに察しお以䞋を実斜したす。 + +- AI を䜿甚しお代衚的なサンプルを特定したす +- ゚ラヌログず異垞に集䞭したす +- むンテリゞェントサンプリングを適甚しおコストを削枛したす + +### 5. ログベヌスの Detector を䜜成する + +以䞋に察するアラヌトをセットアップしたす。 + +- 重倧な゚ラヌパタヌン +- 異垞なログ量 +- 新しい゚ラヌタむプ +- セキュリティに関連するパタヌン + +## ナヌスケヌス + +### ナヌスケヌス 1: メモリリヌクの特定 + +**芳察**: パタヌン分析で「GC pressure」譊告の増加が瀺される + +**AI による支揎**: + +- GC 関連のログパタヌンをグルヌプ化 +- 頻床の増加を匷調 +- メモリメトリクスず盞関 +- 圱響を受けるサヌビストレヌスにリンク + +### ナヌスケヌス 2: セキュリティ問題の怜出 + +**芳察**: 「Authentication failed」ずいう新しいパタヌンが出珟 + +**AI による支揎**: + +- 新芏/垌少パタヌンずしおフラグ付け +- 送信元 IP ごずにクラスタリング +- 異垞なアクセスパタヌンを匷調 +- セキュリティ関連のフィルタヌを提案 + +### ナヌスケヌス 3: デヌタベヌス性胜劣化 + +**芳察**: スロヌク゚リ譊告が増加 + +**AI による支揎**: + +- パタヌンごずにク゚リをグルヌプ化 +- 最も遅いク゚リタむプを特定 +- デヌタベヌスメトリクスず盞関 +- アプリケヌショントレヌスにリンク + +## 制限事項ず考慮点 + +- **パタヌンの品質はログ構造に䟝存したす**: 非構造化ログはパタヌン化が困難です +- **高カヌディナリティフィヌルド**: UUID や䞀意の ID はパタヌンを分割する可胜性がありたす +- **孊習期間**: 異垞怜知には AI がベヌスラむンデヌタを必芁ずしたす +- **コンテキストが鍵**: ログ AI を他のオブザヌバビリティシグナルず組み合わせお䜿甚したす + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +最も効果的なログ分析は、AI を掻甚したパタヌン怜出ずドメむン知識を組み合わせたす。AI でシグナルを浮き圫りにし、専門知識で解釈しおください。 +{{% /notice %}} + +## 次のステップ + +Log Observer の AI 機胜を理解したずころで、アプリケヌションのトラブルシュヌティングのために APM AI Assistant を探玢したしょう。 diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/6-apm-assistant/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/6-apm-assistant/_index.md new file mode 100644 index 0000000000..b409e7ec6a --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/6-apm-assistant/_index.md @@ -0,0 +1,262 @@ +--- +title: APM AI Assistantずむンテリゞェントなトラブルシュヌティング +linkTitle: 6. APM AI Assistant +weight: 6 +--- + +## APM AI Assistantずは + +APM AI Assistantは、コンテキストに沿ったガむダンスの提䟛、トレヌスの分析、調査䞭の次のステップの提案を通じお、アプリケヌションパフォヌマンスの問題のトラブルシュヌティングを支揎するむンテリゞェントな機胜です。APMデヌタを理解し、解決策ぞず導く仮想゚キスパヌトずしお機胜したす。 + +{{% notice title="泚意" style="info" %}} +AI Assistantの機胜は、Splunk Observability Cloudのバヌゞョンや契玄内容によっお異なる堎合がありたす。ここで説明する䞀郚の機胜は、プレビュヌ段階であったり、特定のラむセンスを必芁ずする堎合がありたす。 +{{% /notice %}} + +## 䞻な機胜 + +### 1. トレヌス分析 + +- **自動スパン分析**: 遅いスパンや問題のあるスパンを特定したす +- **ボトルネック怜出**: 分散トレヌス内のパフォヌマンスボトルネックを匷調衚瀺したす +- **゚ラヌパタヌン認識**: ゚ラヌトレヌスをグルヌプ化しお分析したす +- **䟝存関係むンサむト**: サヌビスの䟝存関係ず呌び出しパタヌンを把握したす + +### 2. ガむド付きトラブルシュヌティング + +- **根本原因の提案**: トレヌスデヌタに基づいお、考えられる根本原因を提案したす +- **調査経路**: 次に確認すべき項目を提案したす +- **過去ずの比范**: 珟圚の問題を過去のパタヌンず比范したす +- **解決策の掚奚**: 類䌌の問題に基づいお、考えられる修正策を提瀺したす + +### 3. コンテキスト分析 + +- **自然蚀語による芁玄**: 耇雑なトレヌスをわかりやすい蚀葉で説明したす +- **圱響評䟡**: 問題の範囲ず深刻床を掚定したす +- **サヌビス健党性むンサむト**: サヌビスのパフォヌマンス傟向を芁玄したす +- **異垞の説明**: 䜕が異垞ず刀断されたのかを説明したす + +## AI Assistantによる支揎 + +### シナリオ1: 遅いトレヌスの調査 + +**埓来のアプロヌチ:** + +1. トレヌスのりォヌタヌフォヌルを開く +2. すべおのスパンを手動でスキャンする +3. 所芁時間を蚈算する +4. 最も遅い凊理を特定する +5. 他のトレヌスず盞互参照する +6. 根本原因の仮説を立おる + +**AI Assistantを䜿甚する堎合:** + +1. トレヌスを開く +2. AIが匷調衚瀺: 「checkout-serviceのデヌタベヌスク゚リに2.3秒かかりたした(95パヌセンタむル: 45ms)」 +3. 提案: 「ordersテヌブルのデヌタベヌスむンデックスを確認しおください」 +4. 同じパタヌンを持぀類䌌トレヌスぞのリンクを提瀺 +5. パタヌンが始たった時点を衚瀺 + +### シナリオ2: ゚ラヌパタヌンの理解 + +**AI Assistantが提䟛する情報:** + +- 類䌌゚ラヌのグルヌプ化 +- 頻床分析 +- 最初の発生タむムスタンプ +- 圱響を受ける゚ンドポむントずサヌビス +- ゚ラヌトレヌス党䜓に共通する属性 +- 掚奚される調査ステップ + +## ハンズオン挔習: AI搭茉のAPM機胜を䜿甚する + +{{% notice title="挔習" style="primary" icon="tasks" %}} + +### Step 1: サヌビスむンサむトを探玢する + +1. **APM** → **Services** に移動したす +2. パフォヌマンスデヌタのあるサヌビスを遞択したす +3. AIが生成したむンサむトや芁玄を確認したす: + - サヌビス健党性スコア + - パフォヌマンス傟向 + - 異垞むンゞケヌタヌ + - 䞻芁な問題やボトルネック + +### Step 2: AI支揎によるトレヌス分析 + +1. **APM** → **Traces** に移動したす +2. 遅いトレヌスたたぱラヌトレヌスで絞り蟌みたす +3. トレヌスのりォヌタヌフォヌルビュヌを開きたす +4. AI搭茉機胜を確認したす: + - 匷調衚瀺された問題のあるスパン + - 自動的なクリティカルパスの特定 + - ベヌスラむントレヌスずの比范 + - 掚奚される根本原因 + +### Step 3: 自動根本原因怜出を掻甚する + +1. トレヌスビュヌで **Root Cause** たたは **Insights** パネルを芋぀けたす +2. AIの提案を確認したす: + - どのスパンがボトルネックになっおいるか? + - 通垞の動䜜ず比べお䜕が倉わったのか? + - どのタグや属性が問題ず盞関しおいるか? +3. 提案された調査経路に埓いたす +4. 特定されたコンポヌネントをドリルダりンしたす + +### Step 4: トレヌス比范を䜿甚する + +1. 問題のあるトレヌスを遞択したす +2. **Compare** たたは **Similar Traces** 機胜を探したす +3. AIは次のような情報を衚瀺したす: + - 類䌌する正垞なトレヌス(ベヌスラむン) + - 遅いトレヌスで䜕が異なるのか + - 統蚈的な比范 +4. 異垞なコンポヌネントを特定したす + +{{% /notice %}} + +## むンテリゞェントなトレヌス機胜 + +### クリティカルパスの匷調衚瀺 + +AIは分散トレヌス内のクリティカルパスを自動的に特定したす: + +- **クリティカルスパン**: 党䜓のレむテンシヌに盎接寄䞎するスパン +- **䞊列化可胜なスパン**: 非同期凊理によっお最適化できるスパン +- **埅機時間**: ダりンストリヌムサヌビスを埅機しおいる時間 + +### スパンの異垞怜出 + +AIは次の芁玠を考慮しお異垞なスパンを怜出したす: + +- **所芁時間**: 過去のベヌスラむンずの比范 +- **頻床**: このスパンが出珟する頻床 +- **゚ラヌ率**: このスパン内の゚ラヌず通垞時の゚ラヌ +- **コンテキスト**: 通垞ず異なるタグや属性 + +### サヌビス䟝存関係むンテリゞェンス + +AIはサヌビスアヌキテクチャを理解したす: + +- **䟝存関係マッピング**: サヌビス間の関係を自動的にマッピングしたす +- **圱響分析**: サヌビスの問題が䟝存先に䞎える圱響を予枬したす +- **埪環䟝存怜出**: 問題のある呌び出しパタヌンを特定したす +- **最適化の提案**: アヌキテクチャの改善を掚奚したす + +## AI搭茉のAPMアラヌト + +### スマヌトアラヌト優先順䜍付け + +AIは次の芁玠でアラヌトの優先順䜍付けを支揎したす: + +- **ビゞネスむンパクトスコアリング**: ナヌザヌや収益ぞの圱響を掚定したす +- **過去のコンテキスト**: 過去の類䌌アラヌトず比范したす +- **盞関分析**: 関連するアラヌトをグルヌプ化したす +- **ノむズ削枛**: 停陜性の可胜性が高いものを抑制したす + +### 適応型しきい倀 + +APMベヌスのDetectorで䜿甚できたす: + +- **動的ベヌスラむン**: トラフィックパタヌンに基づいおしきい倀を調敎したす +- **季節性の考慮**: 時間垯や曜日のパタヌンを考慮したす +- **デプロむの考慮**: デプロむむベントを認識したす +- **トラフィック比䟋アラヌト**: トラフィック量の倉化に合わせお調敎したす + +## 自然蚀語機胜 + +### 質問する(利甚可胜な堎合) + +䞀郚のAI Assistant実装では、自然蚀語によるク゚リが可胜です: + +**質問の䟋:** + +- 「checkout-serviceが遅いのはなぜですか?」 +- 「過去1時間で䜕が倉わりたしたか?」 +- 「どの゚ンドポむントで゚ラヌが発生しおいたすか?」 +- 「customer tier enterpriseのトレヌスを衚瀺しおください」 +- 「珟圚のパフォヌマンスを先週ず比范しおください」 + +**AIが提䟛する情報:** + +- 自然蚀語による回答 +- 関連するトレヌスずメトリクス +- デヌタの可芖化 +- 掚奚される次のステップ + +## AI Assistantを䜿甚する際のベストプラクティス + +### 1. 豊富なコンテキストを提䟛する + +AIをよりよく掻甚するために: + +- わかりやすいスパン名を䜿甚したす +- 関連するタグや属性を远加したす +- スパンに゚ラヌの詳现を含めたす +- デプロむむベントにタグを付けたす + +### 2. 信頌し぀぀怜蚌する + +- AIの提案は出発点ずしお掻甚したす +- 実際のデヌタで結果を怜蚌したす +- メトリクスやログず盞互参照したす +- ドメむン知識を適甚したす + +### 3. AIのパタヌンから孊ぶ + +- AIが特定する䞀般的な根本原因に泚目したす +- どのタグが最も有甚か芳察したす +- AIが提案する調査経路を孊習したす +- 繰り返されるパタヌンに基づいお自動化を構築したす + +### 4. フィヌドバックを提䟛する + +AI Assistantがフィヌドバックをサポヌトしおいる堎合: + +- 圹立぀提案にマヌクを付けたす +- 䞍正確な分析を報告したす +- システムはフィヌドバックから孊習したす + +## AI Assistantを他のAI機胜ず組み合わせる + +### 統合ワヌクフロヌ + +1. **アラヌトが発生**(AutoDetect MLディテクタヌ) +2. **Tag Spotlight** で問題を絞り蟌む +3. **APM AI Assistant** が圱響を受けるトレヌスを分析する +4. **Related Content** が関連するダッシュボヌドを提瀺する +5. **Log Observer AI** が盞関するログパタヌンを衚瀺する +6. 完党なコンテキストずずもに **解決** + +### 調査フロヌの䟋 + +```text +Alert: "Latency increased on payment-service" + ↓ +Tag Spotlight: "Region: us-west-1 (87% contribution)" + ↓ +APM AI: "Database span duration increased 450%" + ↓ +Trace Analysis: "Connection pool exhausted" + ↓ +Log Observer AI: Pattern "Connection pool timeout" increased + ↓ +Related Content: Dashboard "Database Connection Health" + ↓ +Root Cause: Recent traffic spike exceeded DB connection limits +``` + +## 制限事項ず考慮事項 + +- **孊習期間**: AIは比范のために過去のデヌタを必芁ずしたす +- **デヌタ品質**: 粟床はトレヌスの完党性ずタグ付けに䟝存したす +- **コンテキストの境界**: AIはビゞネスロゞックを理解しおいたせん +- **プレビュヌ機胜**: 䞀郚の機胜は進化途䞊にある堎合がありたす +- **プラむバシヌ**: 機密デヌタがトレヌス属性に含たれないようにしおください + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +APM AI Assistantは、アプリケヌションが包括的なタグや属性で適切に蚈装されおいる堎合に最も効果を発揮したす。トレヌスデヌタが豊富であるほど、AIによるむンサむトの質も高たりたす。 +{{% /notice %}} + +## 次のステップ + +ワヌクショップのたずめず远加リ゜ヌスに進みたしょう。 diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/7-wrap-up/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/7-wrap-up/_index.md new file mode 100644 index 0000000000..f81dfc7177 --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/7-wrap-up/_index.md @@ -0,0 +1,243 @@ +--- +title: たずめず次のステップ +linkTitle: 7. たずめ +weight: 7 +--- + +## ワヌクショップのたずめ + +おめでずうございたす「Using AI in Splunk Observability Cloud」ワヌクショップを完了したした。プラットフォヌムの AI および ML 機胜に぀いお孊んだ内容を振り返りたしょう。 + +## 重芁なポむント + +### 1. Related Content + +- AI が文脈に応じた関連ダッシュボヌド、ディテクタヌ、リ゜ヌスを提瀺したす +- 調査時のナビゲヌションず発芋を加速したす +- 利甚パタヌンずメタデヌタの関係性から孊習したす +- **ベストプラクティス**: 䞀貫したタグ付けず呜名芏則を䜿甚しおください + +### 2. AutoDetect ず ML 駆動のディテクタヌ + +- 機械孊習によりむンテリゞェントなディテクタヌを自動的に䜜成したす +- 環境固有のパタヌンず季節性に適応したす +- 動的なしきい倀によりアラヌトノむズを削枛したす +- **ベストプラクティス**: ベヌスラむンの確立に 1〜2 週間の時間を確保しおください + +### 3. Tag Spotlight + +- すべおのタグディメンションにわたる AI 駆動の根本原因分析 +- パフォヌマンス問題に寄䞎するタグを自動的に特定したす +- 手動でのフィルタリングず調査の時間を倧幅に節玄したす +- **ベストプラクティス**: すべおのリ゜ヌスに包括的か぀䞀貫したタグを適甚しおください + +### 4. Log Observer AI + +- パタヌン怜出により類䌌ログを自動的にグルヌプ化したす +- 異垞怜出により通垞ず異なるログ゚ントリを匷調衚瀺したす +- むンテリゞェントなフィルタリングが関連フィヌルドを提案したす +- **ベストプラクティス**: 䞀貫したフィヌルド名で構造化ログを䜿甚しおください + +### 5. APM AI Assistant + +- アプリケヌション問題のトラブルシュヌティングのためのむンテリゞェントなガむダンス +- トレヌス内のボトルネックず異垞の自動怜出 +- 自然蚀語によるむンサむトずサマリヌ +- **ベストプラクティス**: 包括的なタグず属性でトレヌスを充実させおください + +### 6. 予枬分析 + +- ML モデルが将来のトレンドずキャパシティニヌズを予枬したす +- 朜圚的な問題のプロアクティブな特定 +- キャパシティプランニングのためのトラフィック予枬 +- **ベストプラクティス**: 正確な予枬のために䞀貫した履歎デヌタを維持しおください + +## AI 駆動の調査ワヌクフロヌ + +これらすべおの AI 機胜がどのように連携するかを以䞋に瀺したす。 + +```text +1. Issue Detected + ├─→ AutoDetect ML Detector triggers alert + └─→ Anomaly clearly identified with dynamic baseline + +2. Context Gathering + ├─→ Related Content surfaces relevant dashboards + ├─→ APM AI Assistant provides service health summary + └─→ Log Observer AI shows correlated log patterns + +3. Root Cause Analysis + ├─→ Tag Spotlight identifies problematic tag values + ├─→ APM AI analyzes traces and highlights bottlenecks + └─→ Log patterns confirm findings + +4. Impact Assessment + ├─→ AI estimates scope (which customers/regions affected) + ├─→ Historical comparison shows severity + └─→ Dependency analysis shows downstream impact + +5. Resolution + ├─→ AI suggests potential fixes based on similar past issues + ├─→ Monitor AI metrics to confirm resolution + └─→ AI learns from the incident for future detection +``` + +## AI の効果を最倧化する + +### デヌタ品質が鍵 + +AI は提䟛されるデヌタの品質に巊右されたす。以䞋を確認しおください。 + +- **包括的なタグ付け**: すべおのリ゜ヌスに䞀貫しおタグを付ける +- **豊富なメタデヌタ**: ビゞネスおよび技術的なコンテキストを含める +- **構造化ログ**: JSON たたはキヌバリュヌ圢匏のログを䜿甚する +- **完党なトレヌス**: すべおのサヌビスず䟝存関係を蚈装する +- **䞀貫した呜名**: 暙準的な呜名芏則を䜿甚する + +### シンプルに始めお、段階的に拡倧 + +1. **1 ぀の AI 機胜から始める**: AutoDetect たたは Tag Spotlight をたずマスタヌしたす +2. **怜蚌ずチュヌニング**: アラヌトを確認し、感床を調敎したす +3. **機胜を远加する**: 远加の AI 機胜を段階的に取り入れたす +4. **ワヌクフロヌを統合する**: 調査においお耇数の AI 機胜を組み合わせたす +5. **自動化する**: AI のむンサむトに基づいおランブックず自動化を構築したす + +### 継続的な改善 + +- **AI の提案を定期的に確認する**: 正確で有甚ですか +- **感床レベルをチュヌニングする**: アラヌトの品質に基づいお調敎したす +- **タグ付けを拡倧する**: その䟡倀を発芋するに぀れお新しいディメンションを远加したす +- **ベヌスラむンを曎新する**: ML モデルが珟圚の通垞状態を反映しおいるこずを確認したす +- **知識を共有する**: AI が発芋に圹立ったパタヌンを文曞化したす + +## 避けるべき䞀般的な萜ずし穎 + +| 萜ずし穎 | 圱響 | 解決策 | +|---------|--------|----------| +| 履歎デヌタが䞍十分 | ベヌスラむンが䞍正確で、異垞怜出も䞍正確になりたす | 効果を刀断する前に 1〜2 週間埅ちたす | +| タグ付けの䞍敎合 | Tag Spotlight が適切に盞関分析できたせん | タグ名ず倀を暙準化したす | +| 感床が高すぎる | 誀怜知によるアラヌト疲劎 | medium から始めお、結果に基づいおチュヌニングしたす | +| AI の提案を無芖する | 䟡倀のあるむンサむトを逃したす | 提案を調査し、フィヌドバックを提䟛したす | +| 構造化されおいないログ | パタヌン怜出胜力が制限されたす | 構造化ログ圢匏に移行したす | +| AI ぞの過床な䟝存 | コンテキスト固有の問題を芋逃したす | AI のむンサむトをドメむンの専門知識ず組み合わせたす | + +## AI のむンパクトを枬定する + +AI の効果を枬定するために、以䞋のメトリクスを远跡しおください。 + +### 怜出メトリクス + +- **MTTD (Mean Time to Detect)**: 問題をより速く発芋できおいたすか +- **誀怜知率**: AutoDetect のアラヌトは正確ですか +- **カバレッゞ**: むンシデントの䜕パヌセントが AI によっお怜出されたしたか + +### 調査メトリクス + +- **MTTR (Mean Time to Resolve)**: より速く解決できおいたすか +- **根本原因たでの時間**: Tag Spotlight はどれくらい早く問題を特定したすか +- **調査ステップ**: 必芁な手動ステップは少なくなりたしたか + +### 効率メトリクス + +- **確認したアラヌト**: シグナルが倚く、ノむズが少なくなりたしたか +- **ダッシュボヌド利甚**: 適切なダッシュボヌドをより速く芋぀けられたすか +- **チヌムのベロシティ**: 同じリ゜ヌスでより倚くの問題を解決できおいたすか + +## 远加リ゜ヌス + +### ドキュメント + +- [Splunk Observability Cloud Documentation](https://docs.splunk.com/observability) +- [AutoDetect Documentation](https://docs.splunk.com/observability/alerts-detectors-notifications/autodetect.html) +- [Tag Spotlight Guide](https://docs.splunk.com/observability/apm/tag-spotlight.html) +- [Log Observer Documentation](https://docs.splunk.com/observability/logs/intro-logconnect.html) + +### トレヌニングず認定 + +- Splunk Observability Cloud Certification +- Advanced APM Training +- ML and AI in Observability webinars + +### コミュニティ + +- Splunk Community Forums +- Splunk Observability Cloud User Group +- Splunk Answers + +### 最新情報の入手 + +- Splunk 補品アップデヌトを賌読する +- Splunk AI/ML 機胜のリリヌスをフォロヌする +- 新しい AI 機胜のプレビュヌプログラムに参加する + +## ハンズオン挔習 + +### 孊習の次のステップ + +1. クリティカルなサヌビスに察しお **AutoDetect ディテクタヌを䜜成する** +2. Troubleshooting MetricSets を䜿甚しお **Tag Spotlight を構成する** +3. 実際のログデヌタで **ログパタヌンを探玢する** +4. これらの機胜を掻甚する **AI を意識したランブックを構築する** +5. **チヌムず共有し**、ベストプラクティスを確立する + +### チャレンゞ挔習 + +さらなる孊習をご垌望の方は、以䞋の高床な挔習を詊しおみおください。 + +#### Challenge 1: AI 駆動のランブックを構築する + +耇数の AI 機胜を組み合わせたランブックを䜜成したす。 + +- AutoDetect ディテクタヌのトリガヌ +- Tag Spotlight が範囲を特定 +- Related Content が関連ダッシュボヌドを発芋 +- Log Observer AI が根本原因を確認 + +#### Challenge 2: タグ付け戊略を最適化する + +- サヌビス党䜓の珟圚のタグを監査する +- Tag Spotlight が苊戊するであろうギャップを特定する +- 远加のディメンションを実装する +- 調査速床の改善を枬定する + +#### Challenge 3: ML ディテクタヌをチュヌニングする + +- クリティカルなメトリクスに察しお AutoDetect をデプロむする +- 2 週間モニタリングする +- アラヌト品質 (真陜性 vs 停陜性) を分析する +- 感床を調敎しお結果を比范する + +#### Challenge 4: AI 匷化されたダッシュボヌドを䜜成する + +- 以䞋を組み合わせたダッシュボヌドを構築したす。 + - ML が予枬する倀 + - 異垞むンゞケヌタヌ + - Tag Spotlight のむンサむト + - Related Content のリンク + +## フィヌドバックの提䟛 + +皆さたのフィヌドバックは AI 機胜の改善に圹立ちたす。 + +- 䞍正確な AI の提案は Splunk Support を通じお報告しおください +- 成功事䟋を Splunk アカりントチヌムず共有しおください +- 新しい AI 機胜のプレビュヌプログラムに参加しおください +- コミュニティでのディスカッションに貢献しおください + +## 謝蟞 + +このワヌクショップにご参加いただきありがずうございたした。AI ず ML はオブザヌバビリティを倉革しおおり、耇雑なシステムを倧芏暡に管理するこずがより容易になっおいたす。これらのツヌルをマスタヌするこずで、珟代のクラりドネむティブ環境においお、ご自身ず組織の成功に向けた基盀を築くこずができたす。 + +### ご質問は + +- Splunk アカりントチヌムにお問い合わせください +- [Splunk Community](https://community.splunk.com/) を蚪問しおください +- [Splunk Docs](https://docs.splunk.com/) をご確認ください + +{{% notice title="次のワヌクショップ" style="primary" icon="forward" %}} +さらに孊習をご垌望ですか他の [Splunk4Ninjas workshops](/ninja-workshops/) もチェックしお、Splunk Observability Cloud の特定の領域に関する専門知識を深めおください。 +{{% /notice %}} + +--- + +**ワヌクショップ完了** お圹に立おたなら幞いです。さあ、AI を掻甚しおオブザヌバビリティの実践を匷化しおいきたしょう diff --git a/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/_index.md b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/_index.md new file mode 100644 index 0000000000..38a95ef598 --- /dev/null +++ b/content/ja/ninja-workshops/ai/10-using-ai-in-o11y/_index.md @@ -0,0 +1,31 @@ +--- +title: Splunk Observability Cloud での AI 掻甚 +linkTitle: Splunk Observability Cloud での AI 掻甚 +weight: 10 +archetype: chapter +time: 90 minutes +authors: ["Pieter Hagen"] +description: Splunk Observability Cloud の AI/ML 機胜 — AutoDetect、Tag Spotlight、Log Observer AI、APM AI Assistant、Predictive Analytics をハンズオンで䜓隓したす。 +draft: true +hidden: false +aliases: + - /ninja-workshops/10-using-ai-in-o11y/ +--- + +**Splunk Observability Cloud** は、プラットフォヌム党䜓に高床な AI および機械孊習機胜を統合し、よりスマヌトに、より速く、より効率的に䜜業を進められるよう支揎したす。これらの AI 駆動型機胜により、問題をより速く特定し、関係性をより深く理解し、自信を持っおデヌタに基づいた意思決定を行えたす。 + +このワヌクショップでは、Splunk Observability Cloud で利甚可胜なさたざたな AI および ML 機胜を、ハンズオン圢匏で䜓隓したす。内容は以䞋のずおりです + +* **Related Content**: オブザヌバビリティデヌタをナビゲヌトする際に、AI が文脈に関連するダッシュボヌド、アラヌト、リ゜ヌスをどのように提瀺するかを確認したす。 +* **AutoDetect**: 機械孊習が、お䜿いの環境固有のパタヌンや挙動に適応するむンテリゞェントなディテクタヌをどのように自動䜜成するかを孊びたす。 +* **Tag Spotlight**: AI 駆動型分析により、タグやメタデヌタ党䜓のパタヌンを分析しおパフォヌマンス問題の根本原因を玠早く特定する方法を探りたす。 +* **Log Observer AI**: AI がむンテリゞェントなパタヌン怜出、異垞の特定、自然蚀語によるむンサむトを通じお、ログ分析をどのように匷化するかを確認したす。 +* **APM AI Assistant**: アプリケヌションパフォヌマンス問題のトラブルシュヌティングや耇雑なトレヌスの理解に察する、AI 駆動型ガむダンスを䜓隓したす。 +* **Predictive Analytics**: ML モデルが将来のトレンドを予枬し、ナヌザヌに圱響が及ぶ前に朜圚的な問題に予防的に察凊する方法を理解したす。 + +このワヌクショップを修了するころには、Splunk Observability Cloud の AI 機胜を以䞋の目的に効果的に掻甚できるようになりたす + +* 怜出たでの平均時間 (MTTD) ず解決たでの平均時間 (MTTR) を短瞮する +* 異垞や通垞ずは異なるパタヌンを自動的に怜出する +* サヌビス、むンフラストラクチャ、ログ間の耇雑な関係をナビゲヌトする +* AI 駆動型むンサむトに基づいた情報に基づいた意思決定を行う diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/1-connect-to-instance.md b/content/ja/ninja-workshops/ai/18-agentic-ai/1-connect-to-instance.md new file mode 100644 index 0000000000..4496b3ff7d --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/1-connect-to-instance.md @@ -0,0 +1,77 @@ +--- +title: EC2 むンスタンスぞの接続 +linkTitle: 1. EC2 むンスタンスぞの接続 +weight: 1 +time: 5 minutes +--- + +## EC2 むンスタンスぞの接続 + +参加者ごずに AWS/EC2 䞊に Ubuntu Linux むンスタンスを甚意しおいたす。 + +* お䜏たいのリヌゞョンのリンクをクリックしお **Splunk Show** むベントにアクセスしたす +* 右䞊の **Enroll** をクリックしたす +* ペヌゞ䞋郚付近にある EC2 むンスタンスの詳现を確認したす + +以䞋のような接続情報が衚瀺されたす。 + +![Connection Information](../images/ConnectionInformation.png) + +**Connection Information** に蚘茉されおいる **SSH Command** に含たれる IP アドレスず **SSH Password** を䜿甚しお、以䞋のいずれかの方法で EC2 むンスタンスに接続したす。 + +* Mac OS / Linux + * ssh splunk@IP address +* Windows 10+ + * OpenSSH クラむアントを䜿甚したす +* それ以前のバヌゞョンの Windows + * Putty を䜿甚したす + +{{% notice title="泚意: 接続を続行するか尋ねられたら 'yes' ず答えおください" style="primary" icon="running" %}} + +![SSH Connection](../images/ssh-connection.png) + +{{% / notice %}} + +{{% notice title="VPN 接続に぀いお" style="green" icon="running" %}} + +オフィスから䜜業しおいお接続に問題がある堎合は、たず瀟内 VPN に接続しおみおください。 + +{{% /notice %}} + +## むンスタンス名の取埗 + +ssh で EC2 むンスタンスにログむンしたら、以䞋のコマンドを䜿甚しおむンスタンス名を取埗したす。 + +```bash +echo $INSTANCE +``` + +このむンスタンス名はあなた専甚のもので、ワヌクショップの埌半で Splunk Observability Cloud 内のデヌタを怜玢する際に䜿甚するため、メモしおおいおください。 + +## Visual Studio Code ぞの接続オプション + +ワヌクショップを通じおいく぀かのファむルを線集したす。ワヌクショップの手順では `vi` ゚ディタを䜿甚するためのヒントが蚘茉されおおり、`nano` ゚ディタも䜿甚できたす。 + +本栌的な IDE を䜿いたい堎合は、ロヌカルマシンで動䜜しおいる Visual Studio Code を EC2 むンスタンス䞊のリモヌトファむル線集に䜿甚できたす。 + +その倧たかな手順は以䞋のずおりです。 + +1. [このリンク](https://code.visualstudio.com/download) からマシンに VS Code をダりンロヌドしおむンストヌルしたす。 +2. VS Code で **Settings** を開き、**Extensions** に移動したす。 +3. **Remote – SSH extension**Microsoft 補を怜玢しおむンストヌルしたす。 + +![Install Remote SSH Extension](../images/InstallRemoteSSH.png) + +1. F1 キヌWindows では Ctrl+Shift+P、Mac OS では Cmd+Shift+Pを抌したす。 +2. **Remote-SSH: Connect to Host** を実行したす。 +3. Splunk Show から SSH コマンドをコピヌしたす: `ssh -p 2222 splunk@EC2_PUBLIC_IP`。 +4. プロンプトが衚瀺されたら、デフォルトの SSH 蚭定ファむルを遞択したす。 +5. もう䞀床 F1 キヌWindows では Ctrl+Shift+P、Mac OS では Cmd+Shift+Pを抌したす。 +6. **Remote-SSH: Connect to Host** を実行したす。 +7. 先ほど远加したホストを遞択したす。VS Code が新しいりィンドりを開き、接続を開始したす。 +8. VS Code の䞊郚に **SSH password** を求めるプロンプトが衚瀺されたす。Splunk Show からパスワヌドをコピヌしおここに入力したす。 +9. **Open Folder** をクリックし、フォルダ名ずしお `/home/splunk` を入力したす。 + +![Open Remote Folder](../images/OpenRemoteFolder.png) + +これで VS Code を䜿っおリモヌトでファむルを線集できるようになりたした。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/10-add-ai-defense-instrumentation.md b/content/ja/ninja-workshops/ai/18-agentic-ai/10-add-ai-defense-instrumentation.md new file mode 100644 index 0000000000..95d7118341 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/10-add-ai-defense-instrumentation.md @@ -0,0 +1,222 @@ +--- +title: AI Defenseむンストルメンテヌションの远加 +linkTitle: 10. AI Defenseむンストルメンテヌションの远加 +weight: 10 +time: 15 minutes +--- + +> 泚意: ワヌクショップのこのセクションでは、耇数のファむルぞの倉曎が必芁です。 +> どこを倉曎すればよいかわからない堎合や、アプリケヌションが動䜜しなくなった堎合は、 +> このセクションの想定される完成圢`~/workshop/agentic-ai/app-with-ai-defense` フォルダ内 +> を参照しおください。 + +Splunk Observability Cloudは +[Cisco AI Defense](https://www.cisco.com/site/us/en/products/security/ai-defense/index.html) +ず連携するこずで、AI゚ヌゞェントの実行時に怜知された[セキュリティおよびプラむバシヌリスク](https://securitydocs.cisco.com/docs/ai-def/user/105473.dita) +を統合的に可芖化し、パフォヌマンスずリスクを䞀元的に監芖できたす。 + +これは **Splunk AI Security Monitoring** ず呌ばれ、以䞋を支揎したす。 + +* プロンプトむンゞェクションやPII挏えいなど、怜知たたはブロックされたセキュリティ・プラむバシヌリスクに関連する゚ヌゞェント、察話、サヌビスを特定する +* レむテンシ、゚ラヌ、その他のパフォヌマンスメトリクスずずもに、リスクの傟向を経時的に远跡する +* 特定のプロンプトやレスポンスに至るたで、トレヌスのコンテキスト内でリスクのある察話を調査する + +このセクションでは、Agentic AIアプリケヌションにAI Defense連携を远加し、 +Splunk Observability Cloudで結果のデヌタを確認したす。 + +## 仕組み + +Splunk AI Security Monitoringは、Pythonベヌスの゚ヌゞェントに察するセキュリティおよびプラむバシヌリスクのトレヌスを自動化するためのむンストルメンテヌションラむブラリ +[opentelemetry-instrumentation-aidefense](https://github.com/signalfx/splunk-otel-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-aidefense) +を提䟛しおいたす。 +このラむブラリは、AI゚ヌゞェントがLLMOpenAIなどやオヌケストレヌションフレヌムワヌクLangChainなどに察しお行う呌び出しに察しお、 +セキュリティテレメトリをキャプチャしおアタッチしたす。 +これにより、すべおのプロンプトずレスポンスをセキュリティガヌドレヌルに照らしお監査でき、 +統合されたOpenTelemetryトレヌス内に蚘録できるこずを保蚌したす。 +具䜓的には、LLMたたはワヌクフロヌのスパンに +`gen_ai.security.event_id attribute` を远加するこずで実珟されたす。 + +## SDKモヌド vs ゲヌトりェむモヌド + +`opentelemetry-instrumentation-aidefense` ラむブラリは、SDKモヌドたたはゲヌトりェむモヌドのいずれかで動䜜したす。 + +* SDKモヌドでは、開発者が `inspect_prompt()` を䜿甚しお明瀺的なセキュリティチェックを远加したす。このオプションは、セキュリティチェックの実装方法や問題ぞの察凊方法を完党に制埡したい開発者に最適です。 +* ゲヌトりェむモヌドでは、LLM呌び出しがCisco AI Defense Gateway経由でプロキシされるため、アプリケヌションコヌドの倉曎は䞍芁です。このモヌドはOpenAI、Anthropicなど䞻芁な商甚LLMでサポヌトされおいたす。 + +このワヌクショップでは、Azure OpenAIずずもにSDKモヌドを利甚したす。 + +## Cisco AI Defense連携のセットアップ + +最初のステップは、[Cisco AI Defenseずの連携をセットアップする](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-security-monitoring/set-up-an-integration-with-cisco-ai-defense)こずです。 + +**Data Management -> Deployed integrations** に移動し、`AI Defense` を怜玢するず、 +この連携がすでに構成されおいるこずがわかりたす。 + +> 泚意: この連携を衚瀺するには、`aiDefenseIntegration` フィヌチャヌフラグを有効にする必芁がありたす + +![AI Defense Config](../images/AIDefenseConfig.png) + +## むンストルメンテヌションパッケヌゞの远加 + +次に、いく぀かのむンストルメンテヌションパッケヌゞをむンストヌルする必芁がありたす。 +`~/workshop/agentic-ai/base-app/requirements.txt` を線集甚に開き、 +以䞋のパッケヌゞを远加したす。 + +```` +# AI Defense instrumentation (Gateway Mode support in v0.2.0+) +splunk-otel-instrumentation-aidefense>=0.2.0 +# We may need to include the AI Defense SDK even with Gateway mode +cisco-aidefense-sdk>=2.0.0 +# HTTP client (httpx is required for Gateway Mode to work) +httpx>=0.24.0 +```` + +{{% notice title="先に進む前に䜜業を確認しおください" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定される完成圢ず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-ai-defense/requirements.txt +``` + +{{% / notice %}} + +## AI Defense SDKのむンポヌト + +゚ヌゞェントにCisco AI Defense保護を远加するために、アプリケヌションを倉曎したしょう。 + +`~/workshop/agentic-ai/base-app/main.py` ファむルを線集甚に開きたす。 + +`Begin: Initialize AI Defense` ず `End: Initialize AI Defense` の行の間に、 +AI Defense保護をむンポヌトしお有効化したす。 + +```python +# Begin: Initialize AI Defense + +from aidefense.runtime import agentsec +agentsec.protect( + api_mode={ + "llm": { + "mode": "monitor", # "enforce" to block violations, "monitor" to log only + "endpoint": os.environ["AI_DEFENSE_API_MODE_LLM_ENDPOINT"], + "api_key": os.environ["AI_DEFENSE_API_MODE_LLM_API_KEY"], + } + } +) + +# End: Initialize AI Defense +``` + +> 重芁: 保護のむンポヌトず有効化は、`langchain_openai` などのLLMクラむアントパッケヌゞをむンポヌトする**前**に実行する必芁がありたす + +{{% notice title="先に進む前に䜜業を確認しおください" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定される完成圢ず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-ai-defense/main.py +``` + +{{% / notice %}} + +### 曎新したDockerむメヌゞのビルド + +新しいタグで曎新埌のDockerむメヌゞをビルドしたす。 + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-ai-defense . +docker push localhost:9999/agentic-ai-app:app-with-ai-defense +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みむメヌゞの利甚を怜蚎しおください。 +> その堎合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファむル内のむメヌゞ名を +> `localhost:9999/agentic-ai-app:app-with-ai-defense` から +> `ghcr.io/splunk/agentic-ai-app:app-with-ai-defense` に曎新しおください。 + +### AI Defense甚のシヌクレット䜜成 + +ワヌクショップむンストラクタヌから提䟛されたドキュメントには、Cisco AI Defenseの怜査APIキヌず゚ンドポむントを保存するためのシヌクレットを䜜成する `kubectl create secret` コマンドが含たれおいたす。 + +ドキュメントから `kubectl create secret` コマンドをコピヌし、 +sshタヌミナルに貌り付けお実行しおください。 + +### Kubernetesマニフェストの曎新 + +`~/workshop/agentic-ai/base-app/k8s.yaml` ファむルを開き、 +AI Defenseが含たれるむメヌゞを䜿甚するようにむメヌゞを曎新したす。 + +```yaml + image: localhost:9999/agentic-ai-app:app-with-ai-defense +``` + +環境倉数セクションの末尟に、以䞋の環境倉数を远加したす。 + +```yaml + - name: AI_DEFENSE_API_MODE_LLM_API_KEY + valueFrom: + secretKeyRef: + name: ai-defense-secret + key: ai-defense-inspection-api-key + - name: AI_DEFENSE_API_MODE_LLM_ENDPOINT + valueFrom: + secretKeyRef: + name: ai-defense-secret + key: ai-defense-inspection-api-endpoint +``` + +{{% notice title="先に進む前に䜜業を確認しおください" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定される完成圢ず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-ai-defense/k8s.yaml +``` + +{{% / notice %}} + +### 曎新したアプリケヌションのデプロむ + +以䞋のようにマニフェストファむルを䜿甚しお、曎新埌のアプリケヌションをデプロむできたす。 + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### Kubernetesでのアプリケヌションのテスト + +新しいアプリケヌションPodが正垞に起動し、叀いPodが残っおいないこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす。 + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +ここでは、アプリケヌションが匕き続き動䜜しおいるこずを確認するだけで構いたせん。 +次のセクションでは、セキュリティリスクを远加し、それがどのように怜知されるかを瀺したす。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/11-detect-security-risks.md b/content/ja/ninja-workshops/ai/18-agentic-ai/11-detect-security-risks.md new file mode 100644 index 0000000000..f4b3600b72 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/11-detect-security-risks.md @@ -0,0 +1,208 @@ +--- +title: Detect Security Risks +linkTitle: 11. Detect Security Risks +weight: 11 +time: 15 minutes +--- + +> 泚: ワヌクショップのこのセクションでは、耇数のファむルぞの倉曎が必芁です。 +> どこに倉曎を加えればよいかわからない堎合や、アプリケヌションが +> 動䜜しなくなった堎合は、このセクションのモデル゜リュヌションを参照しおください。 +> モデル゜リュヌションは `~/workshop/agentic-ai/app-with-security-risk` フォルダにありたす。 + +前のセクションでは、アプリケヌション゚ヌゞェントの1぀の出力に品質問題を泚入するためのラッパヌを远加したした。 + +このセクションでは、同様の挔習を行っおセキュリティリスクを䜜成したす。 + +その埌、これらのリスクが Splunk Observability Cloud にどのように衚瀺されるかを玹介したす。 + +## Activity Specialistの出力を汚染する + +このラッパヌを䜿甚するように Activity Specialist ゚ヌゞェントを倉曎し、 +LLM の出力を改倉したしょう。 + +`~/workshop/agentic-ai/base-app/main.py` ファむルを線集甚に開きたす。 + +`activity_specialist_node` 関数の定矩を、以䞋に瀺すバヌゞョンに眮き換えたす。 +これは、LLM がレスポンスの䞀郚ずしおナヌザヌのクレゞットカヌド番号を含めおしたったシナリオを +シミュレヌトしおおり、明確なセキュリティリスクであり PCI 違反ずなりたす。 + +> ヒント: `vi` ゚ディタヌで倚数の行を䞀括削陀するには、`Shift` + `v` を抌しお `Visual +> Line` モヌドに入り、䞋矢印キヌで削陀したいすべおの行を遞択しおから `d` を抌しお +> 遞択した行を削陀したす。 + +```python +def activity_specialist_node( + state: PlannerState +) -> PlannerState: + base_llm = _create_llm( + "activity_specialist", temperature=0.6, session_id=state["session_id"] + ) + + poisoned_llm = PoisonedChatWrapper( + inner_llm=base_llm, + poison_snippet="Note: I've charged your Visa on file with credit card number 4111 1111 1111 1111." + ) + + agent = _create_react_agent(poisoned_llm, tools=[mock_search_activities]).with_config( + { + "run_name": "activity_specialist", + "tags": ["agent", "agent:activity_specialist"], + "metadata": { + "agent_name": "activity_specialist", + "session_id": state["session_id"], + }, + } + ) + step = f"Curate signature activities for travellers spending a week in {state['destination']}." + + # IMPORTANT: pass a proper list of messages (not stringified) + messages = [ + SystemMessage(content="You are a hotel booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = agent.invoke({"messages": messages}) + + final_message = result["messages"][-1] + state["activities_summary"] = ( + final_message.content + if isinstance(final_message, BaseMessage) + else str(final_message) + ) + state["messages"].append( + final_message + if isinstance(final_message, BaseMessage) + else AIMessage(content=str(final_message)) + ) + state["current_agent"] = "plan_synthesizer" + return state +``` + +{{% notice title="次に進む前に䜜業内容を確認しおください" style="primary" icon="running" %}} + +次のコマンドを実行しお、倉曎内容を期埅される゜リュヌションず比范したす: + +```bash +diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-security-risk/main.py +``` + +{{% / notice %}} + +## 曎新された Docker むメヌゞをビルドする + +新しいタグを付けお、曎新された Docker むメヌゞをビルドしたす: + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-security-risk . +docker push localhost:9999/agentic-ai-app:app-with-security-risk +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みのむメヌゞを +> 䜿甚するこずを怜蚎しおください。そのためには、`~/workshop/agentic-ai/base-app/k8s.yaml` +> ファむルのむメヌゞ名を `localhost:9999/agentic-ai-app:app-with-security-risk` ではなく +> `ghcr.io/splunk/agentic-ai-app:app-with-security-risk` に曎新したす。 + +### Kubernetes マニフェストを曎新する + +`~/workshop/agentic-ai/base-app/k8s.yaml` ファむルを線集甚に開き、 +セキュリティリスクを含むむメヌゞを䜿甚するようにむメヌゞを曎新したす: + +```yaml + image: localhost:9999/agentic-ai-app:app-with-security-risk +``` + +### 曎新されたアプリケヌションをデプロむする + +次のようにマニフェストファむルを䜿甚しお、曎新されたアプリケヌションをデプロむできたす: + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### Kubernetes でアプリケヌションをテストする + +新しいアプリケヌション Pod が正垞に起動し、叀い Pod が存圚しないこずを確認したす: + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす: + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +## Cisco AI Defense でむベントを衚瀺する + +ワヌクショップ参加者は AI Defense アプリケヌションに盎接ログむンするこずはできたせん。 +ただし、AI Defense ダッシュボヌドを衚瀺できれば、このリク゚ストに察しおむベントが +ログに蚘録され、プロンプトに含たれおいたクレゞットカヌド番号が自動的に線集マスク +されおいるこずを確認できたす。 + +![AI Defense Events](../images/AIDefenseEvents.png) + +AI Defense では、特定の皮類のセキュリティ問題を監芖するかブロックするかを指定する +ポリシヌを蚭定できるこずに泚意しおください。今回の堎合、PCI 関連の問題は監芖のみを +行うように遞択しおいたす。 + +## Splunk Observability Cloud でデヌタを衚瀺する + +Splunk Observability Cloud に戻っお、トレヌスが今どのように芋えるかを確認したしょう。 + +`APM` に移動し、`AI agents` を遞択したす。環境名䟋: `agentic-ai-$INSTANCE`が +遞択されおいるこずを確認しおください。ペヌゞにセキュリティリスクが含たれおいるこずが +わかりたす + +![Agents with Security Risks](../images/AgentsWithSecurityRisks.png) + +> セキュリティリスクは `AI overview` ペヌゞや、`plan_synthesizer` ゚ヌゞェントの +> `AI agent` ペヌゞにも衚瀺されるはずです。 + +`APM -> AI trace data` に移動し、最新のトレヌスを読み蟌みたす。 + +゚ヌゞェントフロヌでは、セキュリティリスクが怜出されたこずがわかりたす: + +![Agent Flow With Security Risk](../images/AgentFlowWithSecurityRisk.png) + +`activity_specialist` ゚ヌゞェントの `invoke_agent` スパンを芋るず、LLM がレスポンスの䞭で +顧客のクレゞットカヌド番号を平文で開瀺したため、PCI セキュリティリスクが怜出されおブロック +されたこずがわかりたす: + +![Trace With Security Risk](../images/TraceWithSecurityRisk.png) + +セキュリティリスクをクリックするず、远加の詳现ず Cisco AI Defense でむベントを衚瀺する +ためのリンクが提䟛されたす: + +![Security Risk Details](../images/SecurityRiskDetails.png) + +このスパンの `Span details` を衚瀺するず、`gen_ai.security.event_id` 属性がこのスパンに +含たれおいるこずがわかりたす: + +![Security Event Span Attribute](../images/SecurityEventSpanAttribute.png) + +この属性により、Splunk Observability Cloud のスパンを Cisco AI Defense の察応するむベントず +関連付けるこずができたす。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/12-explore-other-ai-frameworks.md b/content/ja/ninja-workshops/ai/18-agentic-ai/12-explore-other-ai-frameworks.md new file mode 100644 index 0000000000..41815b85a4 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/12-explore-other-ai-frameworks.md @@ -0,0 +1,227 @@ +--- +title: その他の Agentic AI フレヌムワヌクを詊す +linkTitle: 12. その他の Agentic AI フレヌムワヌクを詊す +weight: 12 +time: 15 minutes +--- + +このワヌクショップのこれたでのセクションでは、**LangChain** ず **LangGraph** で構築された Agentic AI アプリケヌションを OpenTelemetry でむンスツルメンテヌションするこずに焊点を圓おおきたした。 + +このセクションでは、察象範囲を広げお**その他の人気のある Agentic AI フレヌムワヌク**を取り䞊げ、利甚可胜なむンスツルメンテヌション手法を抂説したす。 + +倧たかに蚀うず、Agentic AI アプリケヌションを OpenTelemetry でむンスツルメンテヌションするには、**䞻に 2 ぀の遞択肢**がありたす。最適な手法は、䜿甚しおいるフレヌムワヌクず、アプリケヌションに既存のむンスツルメンテヌションが含たれおいるかどうかによっお異なりたす。 + +## 適切なむンスツルメンテヌション手法の遞択 + +### オプション 1: Splunk OpenTelemetry Instrumentation利甚可胜な堎合に掚奚 + +Splunk は、広く䜿われおいるいく぀かの Agentic AI フレヌムワヌク向けに OpenTelemetry むンスツルメンテヌションパッケヌゞを提䟛しおいたす。察応フレヌムワヌクは以䞋のずおりです。 + +* CrewAI +* LangChain/LangGraph +* LlamaIndex +* OpenAI SDK +* OpenAI Agents SDK + +#### このオプションを䜿甚する堎面 + +このアプロヌチは、次のような堎合に遞択しおください。 + +* アプリケヌションが䞊蚘のいずれかのフレヌムワヌクを䜿甚しおいる。 +* 最小限の構成で Splunk Observability Cloud に最適化された **OpenTelemetry むンスツルメンテヌション** を利甚したい。 +* **zero-code** によるむンスツルメンテヌションを奜む。 + +#### 仕組み + +[Zero-code instrumentation integrations](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-monitoring/set-up-ai-agent-monitoring/zero-code-instrumentation#zero-code-instrumentation-integrations-0) の手順に埓っおアプリケヌションをむンスツルメンテヌションしたす。 + +フレヌムワヌクによっおは、次の察応が必芁になる堎合がありたす。 + +* 远加の Splunk OpenTelemetry パッケヌゞのむンストヌル +* 以䞋のようなオプション機胜を有効にするための環境倉数の蚭定: + * LLM のプロンプトず応答のキャプチャ + * LLM 応答の意味的品質の評䟡 + * Cisco AI Defense ずの統合 + +**Note**: これは、ワヌクショップの前半で LangChain ず LangGraph に察しお䜿甚したのず同じアプロヌチで、オプションのプロンプトおよび応答のキャプチャも含たれたす。 + +### オプション 2: サヌドパヌティヌのむンスツルメンテヌションラむブラリ + +フレヌムワヌクが Splunk OpenTelemetry むンスツルメンテヌションで**盎接サポヌトされおいない**堎合は、より広範なフレヌムワヌクをカバヌするサヌドパヌティヌラむブラリを䜿甚できたす。 + +よく䜿甚されるサヌドパヌティヌのむンスツルメンテヌションラむブラリには次のものがありたす。 + +* [LangSmith](https://docs.langchain.com/langsmith/observability): +* [OpenLIT](https://docs.openlit.io/latest/sdk/overview) +* [Traceloop / OpenLLMetry](https://www.traceloop.com/docs/openllmetry/introduction) + +#### このオプションを䜿甚する堎面 + +このアプロヌチは、次のような堎合に適しおいたす。 + +* アプリケヌションがオプション 1 に蚘茉されおいない Agentic AI フレヌムワヌクを䜿甚しおいる +* アプリケヌションが**すでに**サヌドパヌティヌのむンスツルメンテヌションラむブラリで**むンスツルメンテヌション枈み**である +* 既存のコヌドを再むンスツルメンテヌションしたくない + +#### 仕組み + +サヌドパヌティヌラむブラリは通垞、独自のフォヌマットや叀い OpenTelemetry スキヌマでテレメトリヌを出力したす。このデヌタを Splunk Observability Cloud ず統合するには、次の手順を行いたす。 + +1. 出力されたテレメトリヌを最新の OpenTelemetry セマンティック芏玄に倉換する**倉換レむダヌ**を有効にしたす。 +2. OpenTelemetry Collector を次のように構成したす。 + +* 倉換されたデヌタを受信する +* Splunk Observability Cloud に゚クスポヌトする + +ステップごずの手順に぀いおは、次を参照しおください。 +[Translate and collect data from AI applications instrumented with third-party libraries](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-monitoring/set-up-ai-agent-monitoring/translate-data-from-third-party-instrumentation-libraries) + +### たずめ + +| シナリオ | 掚奚オプション | +|--------------------------------------|-----------------------------------------| +| サポヌトされおいるフレヌムワヌク、最小限のセットアップ | Splunk OpenTelemetry Instrumentation | +| サポヌトされおいないフレヌムワヌク | サヌドパヌティヌのむンスツルメンテヌションラむブラリ | +| 既存のサヌドパヌティヌむンスツルメンテヌション | サヌドパヌティヌ + OpenTelemetry 倉換 | + +## CrewAI の䟋 + +CrewAI を䜿った䟋を芋おいきたしょう。ワヌクショップ䞭に䜿甚しおきたトラベルプランナヌアプリケヌションを CrewAI で曞き盎したものです。゜ヌスコヌドは `~/workshop/agentic-ai/crewai` フォルダヌにありたす。 + +CrewAI でぱヌゞェントずタスクを定矩する際に宣蚀的なアプロヌチを䜿甚する点に泚意しおください。たずえば、`~/workshop/agentic-ai/crewai/config/agents.yaml` ファむルでは次のような゚ヌゞェントを定矩しおいたす。 + +```yaml +coordinator: + role: Travel Coordinator + goal: Extract traveler intent and define a clear execution plan for specialists. + backstory: You are a lead travel coordinator managing specialist agents for flights, hotels, and activities. + verbose: true + allow_delegation: false + +flight_specialist: + role: Flight Booking Specialist + goal: Find an appealing and practical round-trip flight option. + backstory: You specialize in concise, high-signal flight recommendations. + verbose: true + allow_delegation: false +``` + +そしお `~/workshop/agentic-ai/crewai/config/tasks.yaml` ファむルでは次のようなタスクを定矩しおいたす。 + +```yaml +coordinate_trip: + description: > + Read the user request and extract key trip details: + origin, destination, travel style, and constraints. + Provide a short execution brief for specialists. + User request: {user_request} + Origin: {origin} + Destination: {destination} + Departure: {departure} + Return: {return_date} + Travellers: {travellers} + expected_output: > + A concise planning brief with extracted details and assumptions. + agent: coordinator +``` + +CrewAI アプリケヌションをむンスツルメンテヌションするために、`requirements.txt` ファむルに次のパッケヌゞが远加されおいる点に泚目しおください。 + +```` +splunk-opentelemetry==2.8.0 +splunk-otel-instrumentation-crewai==0.1.3 +splunk-otel-instrumentation-openai==0.1.0 +splunk-otel-genai-emitters-splunk==0.1.7 +splunk-otel-util-genai==0.1.9 +opentelemetry-instrumentation-flask==0.59b0 +```` + +### CrewAI の䟋のデプロむ + +たず新しい Docker むメヌゞをビルドしお、CrewAI の䟋をデプロむしたしょう。 + +``` bash +cd ~/workshop/agentic-ai/crewai +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:crewai . +docker push localhost:9999/agentic-ai-app:crewai +``` + +> Tip: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みのむメヌゞを䜿甚するこずを怜蚎しおください。 +> その堎合、`~/workshop/agentic-ai/crewai/k8s.yaml` ファむル内のむメヌゞ名を +> `localhost:9999/agentic-ai-app:crewai` から `ghcr.io/splunk/agentic-ai-app:crewai` に倉曎しおください。 + +このバヌゞョンのアプリケヌションには別の environment 名を䜿甚したしょう。 + +```bash +kubectl create configmap instance-config-crewai \ +--from-literal=OTEL_RESOURCE_ATTRIBUTES=deployment.environment=agentic-ai-crewai-$INSTANCE \ +-n travel-agent +``` + +それから、次のようにマニフェストファむルを䜿甚しお CrewAI アプリケヌションをデプロむできたす。 + +``` bash +kubectl apply -f ~/workshop/agentic-ai/crewai/k8s.yaml +``` + +### Kubernetes でアプリケヌションをテスト + +新しいアプリケヌションの Pod が正垞に起動し、叀い Pod が存圚しなくなっおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす。 + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +### Splunk Observability Cloud でデヌタを衚瀺 + +Splunk Observability Cloud に戻っお、CrewAI アプリケヌションのトレヌスを衚瀺したしょう。 + +`APM` に移動し、`AI agents` を遞択したす。environment 名䟋: `agentic-ai-crewai-$INSTANCE`が遞択されおいるこずを確認したす。゚ヌゞェント名がわずかに異なっおいるこずに気付くはずです。 + +![CrewAI Agents](../images/CrewAiAgents.png) + +`APM -> AI trace data` に移動しお、最新のトレヌスを読み蟌みたす。 + +トレヌスには、LangChain/LangGraph 版のアプリケヌションでキャプチャしたものず同様の詳现が衚瀺されおいるはずです。 + +![CrewAI Trace Details](../images/CrewAiTraceDetails.png) + +LangChain/LangGraph のトレヌスず比范しお、CrewAI のトレヌスで䜕か違いに気付きたしたか + +
+ クリックしお答えを衚瀺 + +いく぀かの違いがありたす。 + +* ゚ヌゞェント名が異なりたす`Hotel Booking Specialist` ず `hotel_specialist` +* CrewAI 版には coordinator ず plan synthesizer の゚ヌゞェントが衚瀺されおいたせん +* `travel-planner-crewai` サヌビスのスパンには、りォヌタヌフォヌルビュヌの䞀郚ずしお゚ヌゞェントの指瀺が含たれおいたす + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/13-wrapup.md b/content/ja/ninja-workshops/ai/18-agentic-ai/13-wrapup.md new file mode 100644 index 0000000000..e9a3f1a6c5 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/13-wrapup.md @@ -0,0 +1,19 @@ +--- +title: たずめ +linkTitle: 13. たずめ +weight: 13 +time: 5 minutes +--- + +おめでずうございたす。**Monitoring Agentic AI Applications with Splunk Observability Cloud** ワヌクショップを無事に完了したした。 + +このワヌクショップを通じお、以䞋を達成したした。 + +* **Azure** アカりントを **Splunk Observability Cloud** に接続し、AI むンフラストラクチャ関連のメトリクスを取埗する方法の理解。 +* AI むンフラストラクチャに関する暙準提䟛の **dashboards** および **navigators** の探玢経隓。 +* **LangChain** ず **LangGraph** を䜿甚しお構築された Agentic AI アプリケヌションの **architecture** の理解。 +* Agentic AI アプリケヌションをデプロむし、**OpenTelemetry** で **instrumenting** する実践。 +* Splunk Observability Cloud においお、゚ヌゞェントのパフォヌマンスを把握するために **metrics, traces, and logs** をどのように掻甚できるかを探玢する経隓。 +* Agentic AI アプリケヌションを改修し、**tool calls** ず **agents** を利甚する実践。 +* アプリケヌションに **quality issues** を远加し、**semantic quality evals** を甚いお Splunk Observability Cloud で怜出する実践。 +* アプリケヌションに **AI Defense instrumentation** ず **security risks** を远加し、Splunk Observability Cloud で怜出する実践。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/2-review-azure-ai-metrics.md b/content/ja/ninja-workshops/ai/18-agentic-ai/2-review-azure-ai-metrics.md new file mode 100644 index 0000000000..615491e599 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/2-review-azure-ai-metrics.md @@ -0,0 +1,63 @@ +--- +title: Azure OpenAI のメトリクス、ダッシュボヌド、Navigator を確認する +linkTitle: 2. Azure OpenAI のメトリクス、ダッシュボヌド、Navigator を確認する +weight: 2 +time: 10 minutes +--- + +このワヌクショップでは、Azure 䞊で動䜜する OpenAI モデルを䜿甚したす。 + +Azure OpenAI アプリケヌションのパフォヌマンスは、Azure OpenAI アプリケヌションが Splunk Observability Cloud にメトリクスを送信するように構成するこずで監芖できたす。 + +[ドキュメント](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-infrastructure-monitoring/set-up-data-integrations/cloud-services/azure-openai) に蚘茉されおいる手順に埓っお、Azure アカりントはすでにワヌクショップ甚の Splunk Observability Cloud むンスタンスず連携枈みです。 + +Azure OpenAI のメトリクスが含たれるようにするため、`Cognitive Services` からメトリクスを取埗するよう接続が構成されおいたす。 + +![Azure connection](../images/AzureConnection.png) + +## Azure OpenAI のメトリクス + +Azure OpenAI では、以䞋のような耇数のメトリクスが取埗されたす。 + +* ProcessedPromptTokens +* GeneratedTokens +* AzureOpenAIRequests +* AzureOpenAITimeToResponse +* AzureOpenAIAvailabilityRate +* AzureOpenAITokenPerSecond +* AzureOpenAIContextTokensCacheMatchRate + +**Metrics** -> **Metric finder** に移動し、`ProcessedPromptTokens` メトリクスを怜玢しお **View in chart** をクリックしたす。 + +> 泚: [このリンク](https://app.us1.signalfx.com/#/chart/v2/new?template=default&filters=sf_metric:ProcessedPromptTokens) からも、このメトリクスを **Metric finder** で衚瀺できたす。 + +![Processed Prompt Tokens Metric](../images/ProcessedPromptTokensMetric.png) + +## Azure OpenAI Navigator + +Splunk Observability Cloud は、OpenTelemetry の生成 AI クラむアントおよびモデルサヌバヌのメトリクスを収集し、Azure 䞊で動䜜する Open AI 倧芏暡蚀語モデル (LLM) サヌビスのトヌクン䜿甚量を远跡したす。 + +これらのメトリクスは、Azure OpenAI navigator で確認できたす。**Infrastructure** -> **Overview** -> **AI Frameworks** に移動し、**Azure OpenAI** をクリックしたす。 + +**Table** タブが遞択されおいるこずを確認し、テヌブル内の `gpt-4.1-mini` モデルをクリックしたす。次のような navigator が衚瀺されるはずです。 + +![Azure OpenAI Navigator](../images/AzureOpenAINavigator.png) + +## Azure OpenAI ダッシュボヌド + +Splunk Observability Cloud には、Azure OpenAI 甚の組み蟌みダッシュボヌドが甚意されおおり、以䞋の情報をすぐに確認できたす。 + +* アクティブな Azure OpenAI モデル +* トヌクン䜿甚量 +* 呌び出しのレむテンシ +* モデル別の呌び出し回数 +* Time to first byte +* 合蚈レスポンス時間 +* モデルの可甚性 +* リク゚ストあたりのトヌクン数 +* モデルが凊理したトヌクン数 +* モデルが生成したトヌクン数 + +**Dashboards** に移動し、**Azure OpenAI** を怜玢しおダッシュボヌドを衚瀺したす。 + +![Azure OpenAI Dashboard](../images/AzureOpenAIDashboard.png) diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/3-deploy-collector.md b/content/ja/ninja-workshops/ai/18-agentic-ai/3-deploy-collector.md new file mode 100644 index 0000000000..71cbffd832 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/3-deploy-collector.md @@ -0,0 +1,131 @@ +--- +title: OpenTelemetry Collector のデプロむ +linkTitle: 3. OpenTelemetry Collector のデプロむ +weight: 3 +time: 10 minutes +--- + +このワヌクショップでは、Kubernetes 䞊で実行されおいる Agentic AI アプリケヌションからメトリクス、トレヌス、ログを収集するために OpenTelemetry を䜿甚したす。このセクションでは、Helm を䜿っお Kubernetes クラスタに OpenTelemetry Collector をむンストヌルしたす。これにより、環境からメトリクス、トレヌス、ログを収集しお Splunk に送信できるようになりたす。 + +## Helm を䜿った Collector のむンストヌル + +たず、helm リポゞトリを远加する必芁がありたす。 + +``` bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart +``` + +そしお、リポゞトリが最新であるこずを確認したす。 + +``` bash +helm repo update +``` + +helm chart のデプロむを蚭定するために、`/home/splunk` ディレクトリに `values.yaml` ずいう新しいファむルを䜜成したしょう。 + +``` bash +# switch to the /home/splunk dir +cd /home/splunk +# create a values.yaml file in vi +vi values.yaml +``` + +そしお、以䞋の内容を貌り付けたす。 + +> 貌り付けたコヌドが `vi` によっお自動むンデントされるのを防ぐため、貌り付け前に `:set paste` ず入力しおください。 + +``` yaml +agent: + config: + exporters: + signalfx: + send_otlp_histograms: true +``` + +> vi で倉曎を保存するには、`esc` キヌを抌しおコマンドモヌドに入り、`:wq!` ず入力しおから `enter/return` キヌを抌したす。 + +このカスタム蚭定により、゚クスポヌタヌが受信したヒストグラムメトリクスは、SignalFx 圢匏に倉換されるこずなく OTLP 圢匏のたた Splunk Observability バック゚ンドに送信されたす。この蚭定は、`gen_ai.evaluation.score` のような AI Agent Monitoring で䜿甚されるヒストグラムメトリクスを期埅どおりに凊理するために重芁です。 + +これで、以䞋のコマンドを䜿っお Collector をむンストヌルできたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash + helm upgrade --install splunk-otel-collector --version {{< otel-version >}} \ + --set="splunkObservability.realm=$REALM" \ + --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ + --set="clusterName=$INSTANCE-cluster" \ + --set="environment=agentic-ai-$INSTANCE" \ + --set="splunkPlatform.token=$HEC_TOKEN" \ + --set="splunkPlatform.endpoint=$HEC_URL" \ + --set="splunkPlatform.index=splunk4rookies-workshop" \ + -f values.yaml \ + splunk-otel-collector-chart/splunk-otel-collector +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME: splunk-otel-collector +LAST DEPLOYED: Fri Dec 20 01:01:43 2024 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +NOTES: +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. +``` + +{{% /tab %}} +{{< /tabs >}} + +## Collector が実行されおいるこずを確認する + +以䞋のコマンドで Collector が実行されおいるかを確認できたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-dkn88 1/1 Running 0 53s +splunk-otel-collector-agent-ksmh4 1/1 Running 0 53s +splunk-otel-collector-agent-lc2lf 1/1 Running 0 53s +splunk-otel-collector-k8s-cluster-receiver-dbf64995b-xgm9b 1/1 Running 0 53s +``` + +{{% /tab %}} +{{< /tabs >}} + +## K8s クラスタが O11y Cloud に衚瀺されおいるこずを確認する + +### 新しい Kubernetes Experience を䜿甚する堎合 + +O11y Cloud で新しい Kubernetes Experience を䜿甚する蚭定になっおいる堎合は、このセクションの手順に埓っおください。それ以倖の堎合は、**埓来の Kubernetes Experience を䜿甚する堎合** のセクションを参照しおください。 + +Splunk Observability Cloud で **Infrastructure** -> **Kubernetes overview** に移動し、クラスタ名`-cluster`を远加したす。 + +> ヒント: むンスタンス名を忘れた堎合は、`echo $INSTANCE` コマンドを䜿っおください。 + +![Kubernetes overview filter](../images/k8sOverviewFilter.png) + +**Apply Filters** をクリックするず、以䞋のようなクラスタの抂芁が衚瀺されたす。 + +![Kubernetes overview new experience](../images/k8sOverviewNewExperience.png) + +### 埓来の Kubernetes Experience を䜿甚する堎合 + +Splunk Observability Cloud で **Infrastructure** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、クラスタ名`-cluster`を怜玢したす。 + +> ヒント: むンスタンス名を忘れた堎合は、`echo $INSTANCE` コマンドを䜿っおください。 + +![Kubernetes cluster](../images/k8scluster.png) diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md new file mode 100644 index 0000000000..afdcdc65ee --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md @@ -0,0 +1,60 @@ +--- +title: 4.1 Request Lifecycle +linkTitle: 4.1 Request Lifecycle +weight: 1 +--- + +## アプリケヌションの動䜜内容 + +このアプリケヌションは倧たかに、リク゚ストを受け取り、それを耇数ステップのワヌクフロヌに倉換したす。 + +* coordinator +* flight specialist +* hotel specialist +* activity specialist +* synthesizer + +メむンのフロヌは次のようになっおいたす。 + +```python +@app.route("/travel/plan", methods=["POST"]) +def plan(): + data = request.get_json() + + origin = data.get("origin", "Seattle") + destination = data.get("destination", "Paris") + user_request = data.get( + "user_request", + f"Planning a week-long trip from {origin} to {destination}. " + "Looking for boutique hotel, flights and unique experiences.", + ) + travellers = int(data.get("travellers", 2)) + + result = plan_travel_internal( + origin=origin, + destination=destination, + user_request=user_request, + travellers=travellers + ) + + return jsonify(result), 200 +``` + +これを分かりやすく説明するず、次のずおりです。 + +1. Flask がリク゚ストを受け取りたす +2. `plan_travel_internal()` がワヌクフロヌの状態を構築したす +3. LangGraph がノヌドを実行したす +4. 各ノヌドが状態を曎新したす +5. 最終的な旅皋が JSON ずしお返されたす + +### 理解床チェック + +この API フロヌの䞭で、LangGraph のワヌクフロヌは実際にどこで実行が始たるでしょうか + +
+ クリックしお回答を衚瀺 + +実行は `plan_travel_internal()` の内郚で始たりたす。Flask のルヌトはリク゚ストを受け取っおパラメヌタを抜出するだけです。`plan_travel_internal()` がワヌクフロヌの状態を初期化しお LangGraph のグラフを呌び出し、その埌、ノヌドcoordinator、specialist 矀、synthesizerが状態を曎新しながら実行され、最終的な旅皋が生成されたす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md new file mode 100644 index 0000000000..943441ac34 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md @@ -0,0 +1,58 @@ +--- +title: 4.2 共有状態 +linkTitle: 4.2 共有状態 +weight: 2 +--- + +## LangGraph における共有状態 + +このアプリで最も重芁な LangGraph の抂念は、共有状態オブゞェクトです。 + +```python +class PlannerState(TypedDict): + messages: Annotated[List[AnyMessage], add_messages] + user_request: str + session_id: str + origin: str + destination: str + departure: str + return_date: str + travellers: int + flight_summary: Optional[str] + hotel_summary: Optional[str] + activities_summary: Optional[str] + final_itinerary: Optional[str] + current_agent: str +``` + +この状態は、グラフ内をノヌドからノヌドぞず受け枡されおいきたす。 + +各ノヌドでは以䞋のこずを行いたす。 + +* 状態から倀を読み取る +* 䜕らかの凊理を実行する +* 新しい倀を状態に曞き戻す +* current_agent を蚭定しお次に䜕が起こるかを制埡する + +これは LangGraph の重芁なメンタルモデルである **ステヌトフルなワヌクフロヌオヌケストレヌション** です。 + +### 理解床チェック + +`messages` フィヌルドで䜿われおいる構文をどのように説明したすか + +```python +messages: Annotated[List[AnyMessage], add_messages] +``` + +
+ クリックしお回答を衚瀺 + +`messages: Annotated[List[AnyMessage], add_messages]` は2぀のこずを行っおいたす。 + +* `List[AnyMessage]` はフィヌルドの **型** を定矩しおいたす。これは LangChain のメッセヌゞオブゞェクトsystem、human、AI メッセヌゞのリストです。 +* `Annotated[..., add_messages]` は **LangGraph の動䜜** を远加し、**このフィヌルドぞの曎新がどのように扱われるべきか** をグラフに䌝えたす。 + +具䜓的には、`add_messages` は、ノヌドが新しいメッセヌゞを曞き蟌んだずきに、LangGraph が **既存のリストを䞊曞きするのではなく远加する** こずを意味したす。 +そのため、各ノヌドがメッセヌゞを远加するたびに䌚話履歎が増えおいきたす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md new file mode 100644 index 0000000000..2013a062ec --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md @@ -0,0 +1,78 @@ +--- +title: 4.3 Orchestration +linkTitle: 4.3 Orchestration +weight: 3 +--- +### 実行が始たる堎所 + +メむンのオヌケストレヌションは `plan_travel_internal()` で行われたす。 + +```python +def plan_travel_internal( + origin: str, + destination: str, + user_request: str, + travellers: int, + ) -> Dict[str, object]: + session_id = str(uuid4()) + departure, return_date = _compute_dates() + + initial_state: PlannerState = { + "messages": [HumanMessage(content=user_request)], + "user_request": user_request, + "session_id": session_id, + "origin": origin, + "destination": destination, + "departure": departure, + "return_date": return_date, + "travellers": travellers, + "flight_summary": None, + "hotel_summary": None, + "activities_summary": None, + "final_itinerary": None, + "current_agent": "start", + } + + workflow = build_workflow() + compiled_app = workflow.compile() + + for step in compiled_app.stream(initial_state, config): + node_name, node_state = next(iter(step.items())) + final_state = node_state +``` + +この関数は、次のアプリケヌションラむフサむクルを実装しおいたす。 + +* 初期状態 (initial state) を構築する +* グラフを構築する +* コンパむルする +* ステップごずに実行をストリヌミングする + +### 理解床チェック + +#### 質問 1 + +このコヌドでは、なぜグラフを䞀床だけ呌び出しお最終結果を取埗するのではなく、 +`compiled_app.stream(initial_state, config)` を䜿甚しおいるのでしょうか? + +
+ 回答を衚瀺するにはここをクリック + +ストリヌミングを䜿甚するず、**各ノヌドが実行されるたびにステップごずに**ワヌクフロヌが実行されるためです。 +これにより、アプリケヌションは䞭間状態を芳枬し、どのノヌドが実行䞭かを远跡し、 +最終的な出力を埅぀だけでなく、リアルタむムでワヌクフロヌを監芖できたす。 + +
+ +#### 質問 2 + +なぜグラフを実行する前に `initial_state` を䜜成するのでしょうか? + +
+ 回答を衚瀺するにはここをクリック + +LangGraph のワヌクフロヌは共有されたステヌトオブゞェクトに察しお動䜜するためです。`initial_state` は、 +ワヌクフロヌが進行する䞭でノヌドが読み取り、曎新し、匕き継いでいくための開始デヌタを +提䟛したす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md new file mode 100644 index 0000000000..024c19d082 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md @@ -0,0 +1,65 @@ +--- +title: 4.4 グラフの定矩 +linkTitle: 4.4 グラフの定矩 +weight: 4 +--- + +## グラフの定矩方法 + +グラフは `build_workflow()` の䞭で明瀺的に構築されおいたす。 + +```python +def build_workflow() -> StateGraph: + graph = StateGraph(PlannerState) + graph.add_node("coordinator", lambda state: coordinator_node(state)) + graph.add_node("flight_specialist", lambda state: flight_specialist_node(state)) + graph.add_node("hotel_specialist", lambda state: hotel_specialist_node(state)) + graph.add_node("activity_specialist", lambda state: activity_specialist_node(state)) + graph.add_node("plan_synthesizer", lambda state: plan_synthesizer_node(state)) + graph.add_conditional_edges(START, should_continue) + graph.add_conditional_edges("coordinator", should_continue) + graph.add_conditional_edges("flight_specialist", should_continue) + graph.add_conditional_edges("hotel_specialist", should_continue) + graph.add_conditional_edges("activity_specialist", should_continue) + graph.add_conditional_edges("plan_synthesizer", should_continue) + return graph +``` + +ルヌティングロゞックは次のずおりです。 + +```python +def should_continue(state: PlannerState) -> str: + mapping = { + "start": "coordinator", + "flight_specialist": "flight_specialist", + "hotel_specialist": "hotel_specialist", + "activity_specialist": "activity_specialist", + "plan_synthesizer": "plan_synthesizer", + } + return mapping.get(state["current_agent"], END) +``` + +このグラフは条件付き゚ッゞを䜿っおいたすが、ワヌクフロヌは実質的に盎線的な流れです。 + +* start +* coordinator +* flight specialist +* hotel specialist +* activity specialist +* synthesizer +* end + +### 理解床チェック + +ワヌクフロヌが実質的に盎線的であるにもかかわらず、なぜグラフは +`add_conditional_edges` ず `should_continue()` ルヌタヌを䜿っおいるのでしょうか + +
+ クリックしお回答を衚瀺 + +ワヌクフロヌを **柔軟か぀拡匵可胜** にするためです。珟圚の流れは盎線的ですが、 +ルヌティング関数によっおグラフは状態に基づいお次のノヌドを動的に決定できたす。 +これにより、グラフを再蚭蚈するこずなく、埌から分岐やリトラむ、異なる実行パスを +远加するこずが容易になりたす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md new file mode 100644 index 0000000000..847c1eabb1 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md @@ -0,0 +1,61 @@ +--- +title: 4.5 ノヌドの定矩 +linkTitle: 4.5 ノヌドの定矩 +weight: 5 +--- + +## ノヌドの動䜜の仕組み + +このアプリケヌションにおける LangGraph のノヌドは、状態を受け取っお曎新埌の状態を返す Python 関数にすぎたせん。 + +䟋えば、flight specialist は次のようになりたす。 + +```python +def flight_specialist_node(state: PlannerState) -> PlannerState: + llm = _create_llm( + "flight_specialist", temperature=0.4, session_id=state["session_id"] + ) + + step = ( + f"Find an appealing flight from {state['origin']} to {state['destination']} " + f"departing {state['departure']} for {state['travellers']} travellers." + ) + + messages = [ + SystemMessage(content="You are a flight booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = llm.invoke(messages) + state["flight_summary"] = result.content + state["messages"].append(result) + state["current_agent"] = "hotel_specialist" + return state +``` + +このコヌドは、ノヌドに共通するパタヌンを瀺しおいたす。 + +1. LLM を䜜成たたはアクセスする +2. 構造化された状態からプロンプトを組み立おる +3. モデルを呌び出す +4. 結果を状態に保存する +5. 次のノヌドを蚭定する + +hotel ノヌドず activity ノヌドも同じ構造に埓っおいるため、ワヌクフロヌを説明しやすくなっおいたす。 + +### 理解床チェック + +`flight_specialist` ノヌド甚の LLM を䜜成する際、temperature を `0.4` に指定したした。これは䜕を意味しおいるでしょうか。 + +
+ クリックしお回答を衚瀺 + +temperature は、モデルの応答がどの皋床ランダム、たたは創造的になるかを制埡するパラメヌタヌです。 + +* **䜎い temperature䟋0.0〜0.3**より決定論的で䞀貫性のある応答になりたす +* **䞭皋床およそ 0.4〜0.7**正確性ず創造性のバランスが取れた応答になりたす +* **高い temperature0.8 以䞊**より倚様で創造的になりたすが、予枬しづらくなりたす + +぀たり **temperature=0.4** に蚭定するこずは、`flight_specialist` ゚ヌゞェントが **倧郚分は䞀貫性があり信頌できる応答を生成し぀぀、わずかなばら぀きも含む** 応答を返すこずを意味したす。これは、正確性を求め぀぀も完党に固定的な回答にはしたくないタスクに適しおいたす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md new file mode 100644 index 0000000000..50ec3b50db --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md @@ -0,0 +1,49 @@ +--- +title: 4.6 Message Abstractions +linkTitle: 4.6 Message Abstractions +weight: 6 +--- + +## LangChain Message Abstractions + +このアプリケヌションでは、長いプロンプト文字列を 1 ぀だけ䜿うのではなく、LangChain のメッセヌゞ抜象化を利甚しおいたす。 + +``` python +from langchain_core.messages import ( + AIMessage, + BaseMessage, + HumanMessage, + SystemMessage, +) +``` + +これは、各ノヌドが次の芁玠を分離できるずいう点で重芁です。 + +* system ロヌル +* ナヌザヌタスク +* モデルのレスポンス + +䟋えば、次のようになりたす。 + +```python +messages = [ + SystemMessage(content="You are a flight booking specialist. Provide concise options."), + HumanMessage(content=step), +] +result = llm.invoke(messages) +``` + +### Knowledge Check + +system、human、AI メッセヌゞをどのように定矩したすか + +
+ クリックするず回答が衚瀺されたす + +LangChain ず LangGraph では、メッセヌゞは通垞、誰が発蚀しおいるか、そしお䌚話を導くうえでどのような圹割を担うかによっお分類されたす。 + +* **System message**: AI の振る舞いに関するルヌルずコンテキストを蚭定したす。やり取り党䜓を通じおモデルがどのように応答すべきかを導く、指瀺・制玄・トヌン・ゎヌルを定矩したす。 +* **Human message**: ナヌザヌからの入力です。AI が応答すべき質問・芁求・情報を含みたす。 +* **AI message**: モデルからのレスポンスです。system の指瀺ず human の入力に基づいおアシスタントが生成した出力を衚したす。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md new file mode 100644 index 0000000000..76c3bb9714 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md @@ -0,0 +1,51 @@ +--- +title: 4.7 LLM Creation +linkTitle: 4.7 LLM Creation +weight: 7 +--- + +## LLM の䜜成 + +LLM 自䜓は次の堎所で䜜成されたす。 + +```python +def _create_llm(agent_name: str, *, temperature: float, session_id: str) -> ChatOpenAI: + """Create an ChatOpenAI instance.""" + + model_name = os.getenv("OPENAI_MODEL_NAME", "gpt-4.1-mini") + + return ChatOpenAI( + model = model_name, + temperature = temperature, + # Uses OPENAI_API_KEY automatically from environment + ) +``` + +このアプロヌチでは、モデルの蚭定をワヌクフロヌのロゞックから分離しおいたす。各ノヌドがどの皋床決定論的であるべきか、あるいはどの皋床創造的であるべきかに応じお、異なる temperature を䜿甚できたす。 + +### 知識の確認 + +OpenAI ではなく Azure OpenAI 甚の LLM を䜜成するには、どうすればよいでしょうか + +
+ クリックしお回答を衚瀺 + +Azure OpenAI 甚の LLM を䜜成する堎合、いく぀か違いがありたす。関数は `ChatOpenAI` ではなく `AzureChatOpenAI` オブゞェクトを返したす。 + +たた、Azure 固有のパラメヌタヌ`azure_deployment`、`openai_api_version`、`Azure endpoint`も必芁になりたす。以䞋に䟋を瀺したす。 + +```python +def _create_llm(agent_name: str, *, temperature: float, session_id: str) -> AzureChatOpenAI: + azure_deployment_name = os.getenv("AZURE_OPENAI_DEPLOYMENT_NAME") + azure_openai_api_version = os.getenv("AZURE_OPENAI_API_VERSION") + + return AzureChatOpenAI( + azure_deployment=azure_deployment_name, + openai_api_version=azure_openai_api_version, + temperature=temperature, + model_name = azure_deployment_name, + # AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT environment variables will be used to connect to the LLM + ) +``` + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md new file mode 100644 index 0000000000..859e063b8c --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md @@ -0,0 +1,66 @@ +--- +title: 4.8 Decomposition Pattern +linkTitle: 4.8 Decomposition Pattern +weight: 8 +--- + +### Synthesizer が decomposition パタヌンを瀺す + +最埌のノヌドは、各スペシャリストの出力を1぀の回答に統合したす。 + +```python +def plan_synthesizer_node(state: PlannerState) -> PlannerState: + llm = _create_llm( + "plan_synthesizer", temperature=0.3, session_id=state["session_id"] + ) + + content = json.dumps( + { + "flight": state["flight_summary"], + "hotel": state["hotel_summary"], + "activities": state["activities_summary"], + }, + indent=2, + ) + + response = llm.invoke( + [ + SystemMessage( + content="You are the travel plan synthesiser. Combine the specialist insights into a concise, structured itinerary." + ), + HumanMessage( + content=( + f"Traveller request: {state['user_request']}\n\n" + f"Origin: {state['origin']} | Destination: {state['destination']}\n" + f"Dates: {state['departure']} to {state['return_date']}\n\n" + f"Specialist summaries:\n{content}" + ) + ), + ] + ) + state["final_itinerary"] = response.content + state["messages"].append(response) + state["current_agent"] = "completed" + return state +``` + +これは agentic アプリにおける兞型的なパタヌンです。 + +* 䜜業をスペシャリストぞ分解する +* 䞭間出力を収集する +* 最終的なレスポンスぞ統合する + +これは、この抂芁から抌さえおおくべき䞻芁なアヌキテクチャ䞊の考え方の1぀です。 + +### Knowledge Check + +なぜこのアプリは1぀の゚ヌゞェントに旅行プラン党䜓を生成させるのではなく、別の `plan_synthesizer` ノヌドを䜿うのでしょうか? + +
+ Click here to see the answer + +このシステムは、たず問題を**専門化されたタスク**(フラむト、ホテル、アクティビティ)ぞ分割するためです。各スペシャリストは焊点を絞ったサマリヌを䜜成し、その埌 `plan_synthesizer` ノヌドが**それらの出力を1぀の䞀貫した旅皋に統合したす**。 + +このパタヌンは**モゞュヌル性、信頌性、可芳枬性**を向䞊させたす。各゚ヌゞェントがより小さな問題を扱い、最終ノヌドが結果を統合するためです。 + +
diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/_index.md b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/_index.md new file mode 100644 index 0000000000..6fe94cdf67 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/4-review-agentic-ai-app/_index.md @@ -0,0 +1,49 @@ +--- +title: Agentic AI アプリケヌションのアヌキテクチャ +linkTitle: 4. Agentic AI アプリケヌションのアヌキテクチャ +weight: 4 +time: 15 minutes +--- + +## アプリケヌション抂芁 + +このワヌクショップでは、旅行予玄のための **Agentic AI** アプリケヌションを䜿甚したす。 +このセクションでは、アプリケヌションのアヌキテクチャを抂芳し、 +利甚しおいる **LangChain** ず **LangGraph** の䞻芁な抂念を玹介したす。 + +{{% notice title="LangChain vs. LangGraph" style="green" icon="running" %}} + +**LangChain** は、プロンプト、ツヌル、モデル統合など、倧芏暡蚀語モデルを扱うための +コアずなるビルディングブロックを提䟛したす。**LangGraph** はそれらの抂念を基盀ずしお、 +耇数のコンポヌネント間で耇雑か぀ステヌトフルなワヌクフロヌをオヌケストレヌションしたす。 +端的に蚀えば、**LangChain** は LLM を掻甚した各ステップが䜕をするかを定矩するのに圹立ち、 +**LangGraph** はそれらのステップが Agentic AI アプリケヌションの䞭でどのように +連携するかを制埡するのに圹立ちたす。 + +{{% /notice %}} + +このワヌクショップの䞻な目的は **OpenTelemetry** を甚いおアプリケヌションを蚈装するこずですが、 +アプリケヌションの構成を基本的に理解しおおくこずで、可芳枬性に関する䜜業がより明確になりたす。 +゚ヌゞェント、ツヌル、ワヌクフロヌがどのように構築されおいるかを把握するこずで、 +システムのトレヌスや分析を始めた際に、テレメトリヌが䜕を衚しおいるのかを認識しやすくなりたす。 + +アヌキテクチャを孊びながら実装も確認したい堎合は、 +アプリケヌションの゜ヌスコヌドが EC2 むンスタンスの以䞋の堎所に甚意されおいたす。 + +`~/workshop/agentic-ai/base-app/main.py` + +![Application Architecture](../images/travel-planner-app-architecture.jpg) + +このアプリケヌションは **Flask API** であり、旅行蚈画のリク゚ストを受け取り、 +耇数の LangChain 駆動の LLM ノヌドで構成された **LangGraph** ワヌクフロヌで凊理したす。 +各ノヌドは特定の圹割を担い、共有ステヌトを曎新し、次のステップに匕き継ぎたす。 + +このパヌトでは、以䞋を確認しおいきたす。 + +* リク゚ストのラむフサむクル +* 共有ステヌトモデル +* LangGraph ノヌドの動䜜 +* コヌド内で䜿甚されおいる LangChain の抜象化 +* 可芳枬性が埌ほど重芁になるポむント + +アプリケヌションのアヌキテクチャず実装の詳现に぀いおは、各サブセクションを参照しおください。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/5-deploy-the-app.md b/content/ja/ninja-workshops/ai/18-agentic-ai/5-deploy-the-app.md new file mode 100644 index 0000000000..7d11c247c3 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/5-deploy-the-app.md @@ -0,0 +1,185 @@ +--- +title: Agentic AI アプリケヌションのデプロむ +linkTitle: 5. Agentic AI アプリケヌションのデプロむ +weight: 5 +time: 15 minutes +--- + +## Agentic AI アプリケヌションのデプロむ (Linux) + +たず、アプリケヌションを Linux EC2 むンスタンス䞊で盎接実行するこずから始めたす。 + +### 環境倉数の蚭定 + +ワヌクショップ講垫から提䟛されるドキュメントには、以䞋の環境倉数を蚭定するための `export` コマンドが含たれおいたす。 + +* `OPENAI_API_KEY` +* `OPENAI_BASE_URL` + +これらの環境倉数は、Azure 䞊でホストされおいる OpenAI モデルLite LLM Proxy 経由にアプリケヌションがどう接続するかを指定するものです。 + +ドキュメントから `export` コマンドをコピヌし、ssh タヌミナルに貌り付けお実行しおください。 + +### 仮想環境の䜜成 + +次に、Python の仮想環境を䜜成し、アプリケヌションの実行に必芁なパッケヌゞをむンストヌルしたす。 + +``` bash +cd ~/workshop/agentic-ai/base-app +python3 -m venv .venv +source .venv/bin/activate +pip install -r requirements.txt +``` + +### アプリケヌションの実行 + +そしお、以䞋のコマンドでアプリケヌションを実行できたす。 + +``` bash +python3 main.py +``` + +### アプリケヌションのテスト + +EC2 むンスタンスに接続した 2 ぀目のタヌミナルセッションを開き、以䞋のコマンドを実行しおアプリケヌションをテストしたす。提案された旅行プランが json 圢匏で返されるはずです。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +curl http://localhost:8080/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya—cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku’s Takeshita Street and Meiji Shrine, followed by Omotesando’s stylish cafes.\n5. Day 5: Discover Akihabara’s electronics and anime culture, with a visit to a themed café.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} +``` + +{{% /tab %}} +{{< /tabs >}} + +### アプリケヌションの停止 + +アプリケヌションが正垞に動䜜するこずを確認したら、最初のタヌミナルに戻り、アプリケヌションを停止したす。 + +## Agentic AI アプリケヌションのデプロむ (Kubernetes) + +アプリケヌションが正垞に動䜜するようになったので、次は Kubernetes にデプロむしおみたしょう。 + +### Docker むメヌゞのビルド + +このセクションでは、`~/workshop/agentic-ai/base-app/Dockerfile` にある Dockerfile を䜿甚しおアプリケヌションの Docker むメヌゞをビルドしたす。以䞋のコマンドを実行しおむメヌゞをビルドしたす。 + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:base-app . +docker push localhost:9999/agentic-ai-app:base-app +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みのむメヌゞを䜿甚するこずを怜蚎しおください。 +> その堎合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファむル内のむメヌゞ名を +> `localhost:9999/agentic-ai-app:base-app` から `ghcr.io/splunk/agentic-ai-app:base-app` +> に倉曎しおください。 + +### アプリケヌション甚の Namespace の䜜成 + +アプリケヌションをホストする新しい namespace を䜜成したしょう。 + +``` bash +kubectl create ns travel-agent +``` + +### OpenAI 認蚌情報を含む Secret の䜜成 + +OpenAI の゚ンドポむントずキヌを保存するために、Kubernetes の secret を䜿甚したす。 + +> 泚意: 先ほど `OPENAI_API_KEY` および `OPENAI_BASE_URL` 環境倉数を蚭定したタヌミナルで、必ずこのコマンドを実行しおください。 + +``` bash +{ [ -z "$OPENAI_API_KEY" ] || \ + [ -z "$OPENAI_BASE_URL" ]; } && \ + echo "Error: Missing variables" || \ + kubectl create secret generic openai-api \ + -n travel-agent \ + --from-literal=openai-api-endpoint=$OPENAI_BASE_URL \ + --from-literal=openai-api-key=$OPENAI_API_KEY +``` + +> 泚: Missing variables ずいう゚ラヌが衚瀺された堎合は、講垫から提䟛されたドキュメントの `export` コマンドを䜿甚しお、環境倉数を再床定矩する必芁がありたす。 + +### Kubernetes マニフェストファむルを䜿甚したアプリケヌションのデプロむ + +ビルド枈みの Kubernetes マニフェストは、`~/workshop/agentic-ai/base-app/k8s.yaml` ずいうファむルにありたす。 + +以䞋のようにマニフェストファむルを䜿甚しおアプリケヌションをデプロむできたす。 + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### アプリケヌションが動䜜しおいるこずの確認 + +以䞋のコマンドを䜿甚しお、アプリケヌションの pod が `Running` ステヌタスになっおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +### Kubernetes でのアプリケヌションのテスト + +以䞋のコマンドを実行しおアプリケヌションをテストしたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya—cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku’s Takeshita Street and Meiji Shrine, followed by Omotesando’s stylish cafes.\n5. Day 5: Discover Akihabara’s electronics and anime culture, with a visit to a themed café.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} +``` + +{{% /tab %}} +{{< /tabs >}} + +## トラブルシュヌティング + +トラブルシュヌティングが必芁な堎合は、以䞋のコマンドを䜿甚しおアプリケヌションのログを確認したす。 + +```bash +kubectl logs -l app=travel-planner-langchain -n travel-agent -f +``` diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/6-instrument-the-app.md b/content/ja/ninja-workshops/ai/18-agentic-ai/6-instrument-the-app.md new file mode 100644 index 0000000000..490384c5a7 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/6-instrument-the-app.md @@ -0,0 +1,245 @@ +--- +title: Instrument the Agentic AI Application +linkTitle: 6. Instrument the Agentic AI Application +weight: 6 +time: 15 minutes +--- + +> 泚意: ワヌクショップのこのセクションでは、耇数のファむルを倉曎する必芁がありたす。 +> どこを倉曎すればよいか分からない堎合や、アプリケヌションが +> 動䜜しなくなった堎合は、`~/workshop/agentic-ai/app-with-instrumentation` フォルダにある +> このセクションの想定゜リュヌションを参照しおください。 + +Agentic AI アプリケヌションを OpenTelemetry でむンストルメントしお Kubernetes に +デプロむするには、いく぀かの手順が必芁です。 + +1. むンストルメンテヌションパッケヌゞを `requirements.txt` ファむルに远加する +2. アプリケヌションを `opentelemetry-instrument` で起動するように Dockerfile を曎新する +3. むンストルメンテヌションパッケヌゞを含む新しい Docker むメヌゞをビルドする +4. 環境倉数を含めお Kubernetes マニフェストを曎新する +5. Kubernetes マニフェストをデプロむする + +## Add Instrumentation Packages + +次に、いく぀かのむンストルメンテヌションパッケヌゞをむンストヌルする必芁がありたす。 +`~/workshop/agentic-ai/base-app/requirements.txt` を線集甚に開き、ファむルの末尟に +以䞋のパッケヌゞを远加するこずで、これを実珟できたす。 + +```` +splunk-opentelemetry==2.8.0 +splunk-otel-instrumentation-langchain==0.1.7 +splunk-otel-genai-emitters-splunk==0.1.7 +splunk-otel-util-genai==0.1.9 +opentelemetry-instrumentation-flask==0.59b0 +```` + +これらのパッケヌゞは以䞋のように説明できたす。 + +* `splunk-opentelemetry`: これは OpenTelemetry Python の Splunk ディストリビュヌションで、Python アプリケヌションをむンストルメントしお分散トレヌスを取埗し、Splunk APM ぞレポヌトしたす。 +* `splunk-otel-instrumentation-langchain`: このパッケヌゞは、LangChain LLM/chat ワヌクフロヌ向けの OpenTelemetry むンストルメンテヌションを提䟛したす。 +* `splunk-otel-genai-emitters-splunk`: このパッケヌゞは、Splunk Platform でのストレヌゞずフィルタリングを最適化するため、Evaluation Results ログ向けに Splunk スキヌマの゚ミッタヌを提䟛したす。 +* `splunk-otel-util-genai`: このパッケヌゞには、OpenTelemetry セマンティック芏玄を甚いた生成 AI ワヌクロヌドのむンストルメンテヌションを容易にするための API およびデヌタ型を提䟛するナヌティリティ関数が含たれおいたす。 +* `opentelemetry-instrumentation-flask`: このラむブラリは、OpenTelemetry WSGI ミドルりェアを基盀ずしお、Flask アプリケヌションの Web リク゚ストを远跡したす。 + +{{% notice title="Check your work before proceeding" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定゜リュヌションず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-instrumentation/requirements.txt +``` + +{{% / notice %}} + +## Update the Dockerfile + +次に、OpenTelemetry むンストルメンテヌションを有効化する必芁がありたす。これは、アプリケヌションが +`opentelemetry-instrument` で起動されるよう Dockerfile を曎新するこずで実珟したす。`~/workshop/agentic-ai/base-app/Dockerfile` +ファむルを線集甚に開き、最終行を以䞋のように曎新しおください。 + +```dockerfile +# Run the server with instrumentation +CMD ["opentelemetry-instrument", "python", "main.py"] +``` + +{{% notice title="Check your work before proceeding" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定゜リュヌションず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/Dockerfile ~/workshop/agentic-ai/app-with-instrumentation/Dockerfile +``` + +{{% / notice %}} + +### Build an Updated Docker Image + +新しいタグで曎新された Docker むメヌゞをビルドしたす。 + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-instrumentation . +docker push localhost:9999/agentic-ai-app:app-with-instrumentation +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みむメヌゞの利甚を +> 怜蚎しおください。その堎合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファむル内の +> むメヌゞ名を `localhost:9999/agentic-ai-app:app-with-instrumentation` から +> `ghcr.io/splunk/agentic-ai-app:app-with-instrumentation` に曎新しおください。 + +### Define the Config Map + +アプリケヌションを Kubernetes にデプロむするずき、テレメトリメトリクス、トレヌス、ログが +明確で䞀意の環境識別子ずずもに Splunk Observability Cloud に送信されるようにしたいず考えたす。 +これにより、異なるデプロむメント間でのデヌタのフィルタリング、比范、トラブルシュヌティングが容易になりたす。 + +これを実珟するため、`deployment.environment` ずいう名前の OpenTelemetry リ゜ヌス属性を蚭定したす。 +倀をハヌドコヌドするのではなく、EC2 むンスタンスにすでに存圚する `INSTANCE` 環境倉数から +掟生させたす。これにより、各デプロむメントが正しい環境名で自動的にタグ付けされるこずが +保蚌されたす。 + +この蚭定は Kubernetes ConfigMap に保存し、埌でアプリケヌション Pod に環境倉数ずしお +泚入できるようにしたす。 + +以䞋のコマンドで ConfigMap を䜜成したす。 + +```bash +kubectl create configmap instance-config \ +--from-literal=OTEL_RESOURCE_ATTRIBUTES=deployment.environment=agentic-ai-$INSTANCE \ +-n travel-agent +``` + +このコマンドが行うこず: + +* OpenTelemetry が想定する `OTEL_RESOURCE_ATTRIBUTES` 環境倉数を定矩したす。 +* `$INSTANCE` の倀に応じお、`deployment.environment` を `agentic-ai-shw-1c43` のような倀に蚭定したす。 +* `travel-agent` ネヌムスペヌスに ConfigMap を䜜成したす。 + +この ConfigMap は次のステップで Kubernetes デプロむメントを蚭定する際に参照したす。 + +### Update the Kubernetes Manifest + +OpenTelemetry むンストルメンテヌション、特に AI Agent Monitoring では、むンストルメンテヌションデヌタの +収集、凊理、゚クスポヌト方法を定矩する倚数の環境倉数を蚭定する必芁がありたす。 + +`~/workshop/agentic-ai/base-app/k8s.yaml` ファむルを線集甚に開きたす。むンストルメンテヌション付きの +むメヌゞを䜿甚するように、**image tag** を曎新したす。 + +```yaml + image: localhost:9999/agentic-ai-app:app-with-instrumentation +``` + +同じファむル内で、`Begin: Add Environment Variables` ず `End: Add Environment Variables` ずいう +コメントの間に以䞋の **環境倉数** を远加したす。 + +> ヒント: 内容を貌り付ける前に `:set paste` ず入力するず、`vi` が貌り付けたコヌドを自動むンデントするのを防げたす。 + +```yaml + # Begin: Add Environment Variables + # Service Name + - name: OTEL_SERVICE_NAME + value: "travel-planner" + # Additional OTEL configuration + - name: OTEL_RESOURCE_ATTRIBUTES + valueFrom: + configMapKeyRef: + name: instance-config + key: OTEL_RESOURCE_ATTRIBUTES + - name: SPLUNK_OTEL_AGENT + valueFrom: + fieldRef: + fieldPath: status.hostIP + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: "http://$(SPLUNK_OTEL_AGENT):4317" + - name: OTEL_EXPORTER_OTLP_PROTOCOL + value: "grpc" + - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE + value: "DELTA" + - name: OTEL_PYTHON_EXCLUDED_URLS + value: "^(https?://)?[^/]+(/health)?$" + - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT + value: "true" + - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE + value: "SPAN" + - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS + value: "span_metric,splunk" + - name: SPLUNK_PROFILER_ENABLED + value: "true" + # End: Add Environment Variables +``` + +> 泚意: スクロヌルしないず衚瀺されないテキストがある堎合がありたす。 +> すべおのテキストをコピヌしたこずを確認するため、右䞊隅の +> `Copy text to clipboard` ボタンを䜿甚しおください。 + +> 泚意: yaml ではむンデントが重芁です。新しい環境倉数が +> 既存の環境倉数ず揃っおいるこずを確認しおください。 + +以䞋の環境倉数は Agentic AI モニタリングに固有のものであり、 +以䞋のように説明できたす。 + +* `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE`: これは、OTLP メトリクス゚クスポヌタヌが、゚クスポヌトされるメトリクスに぀いお环積合蚈、デルタ、たたは䜎メモリ向けの temporality を報告するかを決定したす。Agentic AI モニタリングでは `DELTA` に蚭定するこずが掚奚されたす。 +* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT`: これは、Agentic AI アプリケヌションからのメッセヌゞキャプチャを有効/無効にするために䜿甚したす。本ワヌクショップでは `true` に蚭定しおいたす。 +* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE`: これは、メッセヌゞをどのようにキャプチャするかを定矩したす。本ワヌクショップでは `SPAN` に蚭定しおおり、これによりメッセヌゞは span event store を䜿甚しおキャプチャされたす。 +* `OTEL_INSTRUMENTATION_GENAI_EMITTERS`: 本ワヌクショップでは `span_metric,splunk` に蚭定しおおり、これにより span ずメトリクスデヌタの䞡方、および Splunk 固有の機胜がキャプチャされるようになりたす。 + +{{% notice title="Check your work before proceeding" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を想定゜リュヌションず比范しおください。 + +```bash +diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-instrumentation/k8s.yaml +``` + +{{% / notice %}} + +### Deploy the Updated Application + +以䞋のように、マニフェストファむルを䜿甚しお曎新したアプリケヌションをデプロむできたす。 + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### Test the Application in Kubernetes + +新しいアプリケヌション Pod が正垞に起動し、叀い Pod が存圚しなくなったこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす。 + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +## Troubleshooting + +トラブルシュヌティングが必芁な堎合は、以䞋のコマンドでアプリケヌションログを衚瀺できたす。 + +```bash +kubectl logs -l app=travel-planner-langchain -n travel-agent -f +``` diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/7-review-agent-trace-data.md b/content/ja/ninja-workshops/ai/18-agentic-ai/7-review-agent-trace-data.md new file mode 100644 index 0000000000..b37a17cdb8 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/7-review-agent-trace-data.md @@ -0,0 +1,71 @@ +--- +title: Review Agent Trace Data +linkTitle: 7. Review Agent Trace Data +weight: 7 +time: 10 minutes +--- + +## LLMプロバむダヌ蚭定の確認 + +Splunk Observability Cloudには、倧芏暡蚀語モデル (LLM) ず接続するためのむンテグレヌションが含たれおいたす。Splunkはこの接続を利甚しお、アプリケヌションが生成したLLMレスポンスの **セマンティック品質** を評䟡したす。 + +このむンテグレヌションは、ワヌクショップの組織にすでに蚭定枈みです。 + +蚭定を確認するには、**Data Management → Deployed Integrations** に移動し、**Categories** フィルタヌを `LLMs` に蚭定したす。 + +**LLM Providers** を怜玢しお遞択したす。次のプロバむダヌが衚瀺されたす。 + +![LLM Providers](../images/LLMProviders.png) + +`Azure OpenAI O11y Specialists` プロバむダヌをクリックしお詳现を衚瀺したす。 + +![LLM Provider Details](../images/LLMProviderDetails.png) + +この組織では、サンプリングレヌトが **20%** に蚭定されおいたす。これは、Splunkがアプリケヌションで生成されたLLMレスポンスの **平均20%** に぀いおセマンティック品質を評䟡するこずを意味したす。 + +たた、**1分あたり50回の評䟡レヌト制限** も蚭定されおいたす。サンプリングレヌトずレヌト制限は、顧客のニヌズに応じお調敎できたす。サンプリングレヌトが高いほど評䟡デヌタは倚く埗られたすが、トヌクン䜿甚量ずそれに䌎うコストも増加したす。 + +## AI Agent Monitoring蚭定の確認 + +Splunk Observability Cloudには、AI Agent Monitoringに関連する詳现情報の保存に䜿甚するデヌタ゜ヌスを蚭定するペヌゞも甚意されおいたす。遞択肢は次のずおりです。 + +* Data source – Splunk Observability Cloud +* Data source – Splunk logs + +これらの蚭定は、**Settings -> AI Agent Monitoring** に移動しお確認できたす。 + +![AI Agent Monitoring Configuration](../images/AIAgentMonitoringConfiguration.png) + +SplunkはAI Agent Monitoring関連の詳现情報の保存にSplunk Observability Cloudの利甚を掚奚しおいたす。本ワヌクショップでもこの蚭定を採甚しおいたす。 + +## AI Monitoring暩限の確認 + +LLMの䌚話デヌタは機密性を持぀可胜性があるため、この情報ぞのアクセスず閲芧を制埡するための新しいロヌル `ai_monitoring` がSplunk Observability Cloudに远加されたした。 + +![AI Monitoring Role](../images/AIMonitoringRole.png) + +## Splunk Observability Cloudでトレヌスデヌタを衚瀺する + +Splunk Observability Cloudで `APM` に移動し、`Service Map` を遞択したす。環境名 (䟋: `agentic-ai-$INSTANCE`) が遞択されおいるこずを確認しおください。 + +> ヒント: むンスタンス名を忘れた堎合は、`echo $INSTANCE` コマンドを䜿甚しおください + +次のようなサヌビスマップが衚瀺されたす。 + +![Service Map](../images/ServiceMap.png) + +右偎のメニュヌから `Traces` をクリックしたす。次に、実行時間が長めのトレヌスのいずれかを遞択したす。次の䟋のような衚瀺になりたす。 + +![Trace](../images/Trace.png) + +**Agent flow** セクションに゚ヌゞェント名 (coordinator、flight-specialist など) が衚瀺されおいないこずに泚目しおください。 + +䞋にスクロヌルし、トレヌス内のAIむンタラクションのいずれかをクリックしたす。プロンプトずレスポンスがキャプチャされおいるこずが確認できたす。たた、このトレヌスに察するセマンティック品質評䟡の結果も確認できたす。 + +![Trace Details](../images/TraceDetails.png) + +次に、`APM` に移動し、`AI agents` を遞択したす。環境名 (䟋: `agentic-ai-$INSTANCE`) が遞択されおいるこずを確認しおください。ペヌゞが空になっおいるこずに気付くでしょう。 + +![Agents](../images/Agents.png) + +これらの蚈装の問題に぀いおは、次のセクションで察凊したす。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/8-add-tool-calls.md b/content/ja/ninja-workshops/ai/18-agentic-ai/8-add-tool-calls.md new file mode 100644 index 0000000000..cf8c4bcc95 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/8-add-tool-calls.md @@ -0,0 +1,492 @@ +--- +title: Add Tool Calls +linkTitle: 8. Add Tool Calls +weight: 8 +time: 15 minutes +--- + +> 泚意: ワヌクショップのこのセクションでは、耇数のファむルを倉曎する必芁がありたす。 +> どこを倉曎すればよいかわからない堎合や、アプリケヌションが +> 動䜜しなくなった堎合は、このセクションのモデル゜リュヌションを参照しおください。 +> モデル゜リュヌションは `~/workshop/agentic-ai/app-with-agents-and-tools` フォルダにありたす。 + +前のセクションでは、゚ヌゞェントが新しい **Agents** ペヌゞにも、 +トレヌス䞊郚の **Agent flow** にも衚瀺されないこずがわかりたした。 + +その理由は、珟圚のアプリケヌションが゚ヌゞェントを䜿甚しおおらず、代わりに +LLM を盎接呌び出しおいるためです。 + +぀たり、珟時点では、私たちのアプリは台本通りの劇のようなものです。すべおのセリフずすべおの動䜜は +コヌド内に曞かれおいたす。LLM を呌び出すずきは、特定のセリフを読むようにお願いしおいるだけです。 +LLM が遞択を行わないため、Observability for AI のむンストルメンテヌションは +LLM を自埋的な゚ヌゞェントずしお認識したせん。 + +次のセクションでは、LLM に **tools** ず、それらをどのように䜿甚するかを +決定する暩限を䞎えたす。゚ヌゞェント型モデルに移行するこずで、LLM は +**Tool Calls** を生成し始めたす。OpenTelemetry むンストルメンテヌションがこれらの +やり取りをキャプチャするこずで、LLM の思考プロセスずツヌルの䜿甚状況を確認でき、 +各゚ヌゞェントが Splunk Observability Cloud で衚珟されるようになりたす。 + +## Direct Invocation vs. Agentic Traces + +これらの倉曎を行う前に、LLM を盎接呌び出す堎合ず゚ヌゞェント経由で呌び出す堎合ずで、 +トレヌスがどのようにキャプチャされるかをもう少し詳しく芋おみたしょう。 + +**盎接呌び出しのトレヌス:** + +`llm.invoke()` を呌び出すず、むンストルメンテヌションは暙準的な「Chat」たたは「Completion」スパンを認識したす。 +プロンプトずレスポンスを蚘録したす。゚ヌゞェントフレヌムワヌクによっお管理される +「ルヌプ」や「ツヌル呌び出し」のロゞックが存圚しないため、Splunk Observability Cloud は +そのスパンを「゚ヌゞェント」ずしお分類するために必芁なメタデヌタを認識したせん。 + +**゚ヌゞェント型のトレヌス:** + +゚ヌゞェント䟋: `create_react_agent`を䜿甚するず、 +フレヌムワヌクは実行を特定の「Agent」スパンず「Tool」スパンでラップしたす。これらの +スパンには、OpenTelemetry に「これは単なるチャットではなく、特定のツヌルを䜿甚した +掚論ルヌプである」ず䌝えるメタデヌタが含たれおいたす。これによっお、 +Agents ペヌゞずトレヌス可芖化の Agent Flow 図が衚瀺されるようになりたす。 + +## Make a Backup + +Python コヌドを倉曎する前に、次のコマンドを䜿甚しお `main.py` ファむルの +バックアップを䜜成しおください: + +```bash +cp ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/base-app/main.py.bak +``` + +## Add Import Statements + +`~/workshop/agentic-ai/base-app/main.py` ファむルを開いお線集したす。 + +`Begin: Add Import Statements` ず `End: Add Import Statements` ず曞かれた行の間に、 +次の import 文を远加しおください: + +```python +# Begin: Add Import Statements + +from langchain_core.tools import tool +from langchain.agents import ( + create_agent as _create_react_agent, # type: ignore[attr-defined] +) + +# End: Add Import Statements +``` + +## Add Tools + +同じ `main.py` ファむル内で、`Begin: Tool Definitions` ず `End: Tool Definitions` ず +曞かれた行の間に、ツヌル定矩を远加しおください: + +```python +# Begin: Tool Definitions + +@tool +def mock_search_flights(origin: str, destination: str, departure: str) -> str: + """Return mock flight options for a given origin/destination pair.""" + # create a local random.Random instance + seed = hash((origin, destination, departure)) % (2**32) + rng = random.Random(seed) + airline = rng.choice(["SkyLine", "AeroJet", "CloudNine"]) + fare = rng.randint(700, 1250) + + return ( + f"Top choice: {airline} non-stop service {origin}->{destination}, " + f"depart {departure} 09:15, arrive {departure} 17:05. " + f"Premium economy fare ${fare} return." + ) + + +@tool +def mock_search_hotels(destination: str, check_in: str, check_out: str) -> str: + """Return mock hotel recommendation for the stay.""" + seed = hash((destination, check_in, check_out)) % (2**32) + rng = random.Random(seed) + name = rng.choice(["Grand Meridian", "Hotel LumiÚre", "The Atlas"]) + rate = rng.randint(240, 410) + + return ( + f"{name} near the historic centre. Boutique suites, rooftop bar, " + f"average nightly rate ${rate} including breakfast." + ) + + +@tool +def mock_search_activities(destination: str) -> str: + """Return a short list of signature activities for the destination.""" + data = DESTINATIONS.get(destination.lower(), DESTINATIONS["paris"]) + bullets = "\n".join(f"- {item}" for item in data["highlights"]) + return f"Signature experiences in {destination.title()}:\n{bullets}" + +# End: Tool Definitions +``` + +## Configure the Application for AI Agent Monitoring + +珟圚、私たちのアプリケヌションは LLM を䜜成し、次のように呌び出しおいたす: + +```python +def flight_specialist_node(state: PlannerState) -> PlannerState: + llm = _create_llm( + "flight_specialist", temperature=0.4, session_id=state["session_id"] + ) + ... + result = llm.invoke(messages) + ... +``` + +AI Agent Monitoring のためには、代わりに゚ヌゞェント名を含むメタデヌタを䌎う゚ヌゞェントを䜜成し、 +LLM ではなく゚ヌゞェントを呌び出す必芁がありたす。 + +{{% notice title="LangChain Agents" style="green" icon="running" %}} + +次のステップでは、アプリケヌションに **agents** を远加したす。しかし、LangChain の文脈においお +゚ヌゞェントずは正確に䜕でしょうか + +[LangChain ドキュメント](https://docs.langchain.com/oss/python/langchain/agents) によるず: + +「゚ヌゞェントは、蚀語モデルずツヌルを組み合わせお、タスクに぀いお掚論し、 +どのツヌルを䜿甚するかを決定し、解決策に向けお反埩的に +䜜業できるシステムを䜜成したす。」 + +実際のずころ、これはモデルがテキストの生成だけに限定されないこずを意味したす。代わりに、 +利甚可胜な **tools**API、デヌタベヌス、コヌド実行などの䞭から遞択しお +タスクを完了させるこずができたす。 + +このスタむルの゚ヌゞェントは、しばしば **LangChain ReAct agent** ず呌ばれたす。 + +ReAct は **Reasoning + Acting** の略です。゚ヌゞェントは次のルヌプで動䜜したす: + +* タスクに぀いお簡単に掚論する、 +* 関連するツヌルを遞択しお呌び出す、 +* 結果を芳察する、 +* 新しい情報を䜿甚しお次のステップを決定する。 + +このプロセスは、゚ヌゞェントが最終的な回答を生成するのに十分な情報を集めるたで繰り返されたす。 + +{{% /notice %}} + +`coordinator_node`、`flight_specialist_node`、`hotel_specialist_node`、 +`activity_specialist_node`、`plan_synthesizer_node` 関数の定矩を以䞋に眮き換えおください: + +> ヒント: `vi` ゚ディタで倚数の行を䞀括削陀するには、`Shift` + `v` を抌しお `Visual +> Line` モヌドに切り替え、䞋矢印キヌを䜿っお削陀したい行をすべお遞択した埌、`d` を抌しお +> 遞択した行を削陀したす。 + +```python +def coordinator_node( + state: PlannerState +) -> PlannerState: + llm = _create_llm("coordinator", temperature=0.2, session_id=state["session_id"]) + agent = _create_react_agent(llm, tools=[]).with_config( + { + "run_name": "coordinator", + "tags": ["agent", "agent:coordinator"], + "metadata": { + "agent_name": "coordinator", + "session_id": state["session_id"], + }, + } + ) + system_message = SystemMessage( + content=( + "You are the lead travel coordinator. Extract the key details from the " + "traveller's request and describe the plan for the specialist agents." + ) + ) + + result = agent.invoke({"messages": [system_message] + list(state["messages"])}) + final_message = result["messages"][-1] + state["messages"].append( + final_message + if isinstance(final_message, BaseMessage) + else AIMessage(content=str(final_message)) + ) + state["current_agent"] = "flight_specialist" + return state + + +def flight_specialist_node( + state: PlannerState +) -> PlannerState: + llm = _create_llm( + "flight_specialist", temperature=0.4, session_id=state["session_id"] + ) + agent = _create_react_agent(llm, tools=[mock_search_flights]).with_config( + { + "run_name": "flight_specialist", + "tags": ["agent", "agent:flight_specialist"], + "metadata": { + "agent_name": "flight_specialist", + "session_id": state["session_id"], + }, + } + ) + step = ( + f"Find an appealing flight from {state['origin']} to {state['destination']} " + f"departing {state['departure']} for {state['travellers']} travellers." + ) + + # IMPORTANT: pass a proper list of messages (not stringified) + messages = [ + SystemMessage(content="You are a flight booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = agent.invoke({"messages": messages}) + final_message = result["messages"][-1] + state["flight_summary"] = final_message.content if isinstance(final_message, BaseMessage) else str(final_message) + state["messages"].append(final_message if isinstance(final_message, BaseMessage) else AIMessage(content=str(final_message))) + state["current_agent"] = "hotel_specialist" + return state + + +def hotel_specialist_node( + state: PlannerState +) -> PlannerState: + llm = _create_llm( + "hotel_specialist", temperature=0.5, session_id=state["session_id"] + ) + agent = _create_react_agent(llm, tools=[mock_search_hotels]).with_config( + { + "run_name": "hotel_specialist", + "tags": ["agent", "agent:hotel_specialist"], + "metadata": { + "agent_name": "hotel_specialist", + "session_id": state["session_id"], + }, + } + ) + step = ( + f"Recommend a boutique hotel in {state['destination']} between {state['departure']} " + f"and {state['return_date']} for {state['travellers']} travellers." + ) + + # IMPORTANT: pass a proper list of messages (not stringified) + messages = [ + SystemMessage(content="You are a hotel booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = agent.invoke({"messages": messages}) + + final_message = result["messages"][-1] + state["hotel_summary"] = ( + final_message.content + if isinstance(final_message, BaseMessage) + else str(final_message) + ) + state["messages"].append( + final_message + if isinstance(final_message, BaseMessage) + else AIMessage(content=str(final_message)) + ) + state["current_agent"] = "activity_specialist" + return state + + +def activity_specialist_node( + state: PlannerState +) -> PlannerState: + llm = _create_llm( + "activity_specialist", temperature=0.6, session_id=state["session_id"] + ) + agent = _create_react_agent(llm, tools=[mock_search_activities]).with_config( + { + "run_name": "activity_specialist", + "tags": ["agent", "agent:activity_specialist"], + "metadata": { + "agent_name": "activity_specialist", + "session_id": state["session_id"], + }, + } + ) + step = f"Curate signature activities for travellers spending a week in {state['destination']}." + + # IMPORTANT: pass a proper list of messages (not stringified) + messages = [ + SystemMessage(content="You are a hotel booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = agent.invoke({"messages": messages}) + + final_message = result["messages"][-1] + state["activities_summary"] = ( + final_message.content + if isinstance(final_message, BaseMessage) + else str(final_message) + ) + state["messages"].append( + final_message + if isinstance(final_message, BaseMessage) + else AIMessage(content=str(final_message)) + ) + state["current_agent"] = "plan_synthesizer" + return state + +def plan_synthesizer_node(state: PlannerState) -> PlannerState: + llm = _create_llm( + "plan_synthesizer", temperature=0.3, session_id=state["session_id"] + ) + + agent = _create_react_agent(llm, tools=[]).with_config( + { + "run_name": "plan_synthesizer", + "tags": ["agent", "agent:plan_synthesizer"], + "metadata": { + "agent_name": "plan_synthesizer", + "session_id": state["session_id"], + }, + } + ) + + system_content = ( + "You are the travel plan synthesiser. Combine the specialist insights into a " + "concise, structured itinerary covering flights, accommodation and activities." + ) + + content = json.dumps( + { + "flight": state["flight_summary"], + "hotel": state["hotel_summary"], + "activities": state["activities_summary"], + }, + indent=2, + ) + + out = agent.invoke( + { + "messages": [ + SystemMessage(content=system_content), + HumanMessage( + content=( + f"Traveller request: {state['user_request']}\n\n" + f"Origin: {state['origin']} | Destination: {state['destination']}\n" + f"Dates: {state['departure']} to {state['return_date']}\n\n" + f"Specialist summaries:\n{content}" + ) + ), + ] + } + ) + # 1) Extract the assistant’s final text + final_msg = next(m for m in reversed(out["messages"]) if isinstance(m, AIMessage)) + state["final_itinerary"] = final_msg.content + + # 2) Append the new messages to your ongoing conversation + state["messages"].extend(out["messages"]) # or append just final_msg + + state["current_agent"] = "completed" + return state +``` + +flight、hotel、activity の各スペシャリスト゚ヌゞェントを䜜成する際に、ツヌルを枡しおいるこずに +泚意しおください。゚ヌゞェントが呌び出されるず、LLM はリク゚ストを満たすために +ツヌルを呌び出すべきかどうかを刀断したす。 + +{{% notice title="Check your work before proceeding" style="primary" icon="running" %}} + +次のコマンドを実行しお、倉曎内容を期埅される゜リュヌションず比范しおください: + +```bash +diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-agents-and-tools/main.py +``` + +{{% / notice %}} + +## Build an Updated Docker Image + +新しいタグで曎新された Docker むメヌゞをビルドしたす: + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-agents-and-tools . +docker push localhost:9999/agentic-ai-app:app-with-agents-and-tools +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みの +> むメヌゞを䜿甚するこずを怜蚎しおください。そのためには、 +> `~/workshop/agentic-ai/base-app/k8s.yaml` ファむル内のむメヌゞ名を `localhost:9999/agentic-ai-app:app-with-agents-and-tools` +> ではなく `ghcr.io/splunk/agentic-ai-app:app-with-agents-and-tools` に曎新したす。 + +### Update the Kubernetes Manifest + +`~/workshop/agentic-ai/base-app/k8s.yaml` ファむルを開いお線集し、 +゚ヌゞェントずツヌルを含むむメヌゞを䜿甚するように +むメヌゞを曎新したす: + +```yaml + image: localhost:9999/agentic-ai-app:app-with-agents-and-tools +``` + +### Deploy the Updated Application + +曎新されたアプリケヌションは、マニフェストファむルを䜿甚しお次のようにデプロむできたす: + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### Test the Application in Kubernetes + +新しいアプリケヌション Pod が正垞に起動し、叀い Pod がもう存圚しないこずを確認しおください: + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす: + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +## View Data in Splunk Observability Cloud + +Splunk Observability Cloud に戻り、トレヌスが今どのように芋えるかを確認しおみたしょう。 + +`APM` に移動し、`AI agents` を遞択したす。環境名䟋: `agentic-ai-$INSTANCE`が +遞択されおいるこずを確認しおください。ペヌゞが衚瀺されるようになっおいるこずに +気付くでしょう + +![Agents](../images/Agents-v2.png) + +`APM -> AI trace data` に移動したす。これは、AI 関連のコンテンツを含むトレヌスを +怜玢できる新しいペヌゞです: + +![Agents](../images/AI-trace-data.png) + +環境名䟋: `agentic-ai-$INSTANCE`が遞択されおいるこずを確認しおください。 +新しいトレヌスの 1 ぀を遞択したす。Agent flow にすべおの゚ヌゞェントが衚瀺されおいるのがわかりたす + +![Trace](../images/Trace-v2.png) + +ツヌル呌び出しも確認できたす: + +>泚意: ツヌル呌び出しの詳现を衚瀺するには、画面右偎で `AI details` から `Span details` に +> 切り替えおください。 + +![Trace](../images/TraceWithToolCalls.png) diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/9-detect-quality-issue.md b/content/ja/ninja-workshops/ai/18-agentic-ai/9-detect-quality-issue.md new file mode 100644 index 0000000000..0fe713a526 --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/9-detect-quality-issue.md @@ -0,0 +1,185 @@ +--- +title: Detect Quality Issue +linkTitle: 9. Detect Quality Issue +weight: 9 +time: 15 minutes +--- + +> 泚意: このワヌクショップのセクションでは、耇数のファむルを倉曎する必芁がありたす。 +> 倉曎箇所が分からない堎合や、アプリケヌションが動䜜しなくなった堎合は、 +> このセクションのモデル゜リュヌションを `~/workshop/agentic-ai/app-with-quality-issue` フォルダヌで参照しおください。 + +これたでのセクションでは、アプリケヌションを OpenTelemetry で蚈装し、 +゚ヌゞェント応答の意味的な品質を評䟡するように構成したした。 + +このセクションでは、アプリケヌションにいく぀かの品質問題を远加し、 +Splunk Observability Cloud がこれらの問題をどのように怜出できるかを確認したしょう。 + +## About the Poisoned Chat Wrapper + +このセクションでは、既存の `ChatModel` をラップしお出力を傍受し「ポむズン」する、 +`PoisonedChatWrapper` ずいうカスタムクラスを䜿甚したす。このアプロヌチを採甚したのは、 +OpenTelemetry の蚈装で出力がキャプチャされる前に、出力を傍受できるようにするためです。 + +このしくみに぀いお詳しく知りたい堎合は、`poison_chat_wrapper.py` ファむルを確認しおください。 + +## Poison the Hotel Specialist Output + +次に、hotel specialist ゚ヌゞェントを倉曎しお、このラッパヌを䜿甚し、LLM の出力を改倉したす。 +たず、`~/workshop/agentic-ai/base-app/main.py` ファむルを倉曎し、 +`Begin: Add Import Statements` ず `End: Add Import Statements` の行の間に、 +以䞋の import 文を远加したす。 + +```python +from poison_chat_wrapper import PoisonedChatWrapper +``` + +> 泚意: この新しい import 文は、これたでに远加した他の import 文に加えお远加したす。 + +次に、`hotel_specialist_node` 関数の定矩を以䞋の内容で眮き換えたす。 + +> ヒント: `vi` ゚ディタヌで䞀括しお倧量の行を削陀するには、`Shift` + `v` を抌しお `Visual Line` モヌドに入り、 +> 䞋矢印キヌで削陀したい行をすべお遞択しおから、`d` を抌しお遞択した行を削陀したす。 + +```python +def hotel_specialist_node( + state: PlannerState +) -> PlannerState: + base_llm = _create_llm( + "hotel_specialist", temperature=0.5, session_id=state["session_id"] + ) + + poisoned_llm = PoisonedChatWrapper( + inner_llm=base_llm, + poison_snippet="Note: I think this hotel is pretty terrible, best of luck if you stay there!" + ) + + agent = _create_react_agent(poisoned_llm, tools=[mock_search_hotels]).with_config( + { + "run_name": "hotel_specialist", + "tags": ["agent", "agent:hotel_specialist"], + "metadata": { + "agent_name": "hotel_specialist", + "session_id": state["session_id"], + }, + } + ) + step = ( + f"Recommend a boutique hotel in {state['destination']} between {state['departure']} " + f"and {state['return_date']} for {state['travellers']} travellers." + ) + + # IMPORTANT: pass a proper list of messages (not stringified) + messages = [ + SystemMessage(content="You are a hotel booking specialist. Provide concise options."), + HumanMessage(content=step), + ] + + result = agent.invoke({"messages": messages}) + + final_message = result["messages"][-1] + state["hotel_summary"] = ( + final_message.content + if isinstance(final_message, BaseMessage) + else str(final_message) + ) + state["messages"].append( + final_message + if isinstance(final_message, BaseMessage) + else AIMessage(content=str(final_message)) + ) + state["current_agent"] = "activity_specialist" + return state +``` + +{{% notice title="Check your work before proceeding" style="primary" icon="running" %}} + +以䞋のコマンドを実行しお、倉曎内容を期埅される゜リュヌションず比范したす。 + +```bash +diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-quality-issue/main.py +``` + +{{% / notice %}} + +## Build an Updated Docker Image + +新しいタグで曎新された Docker むメヌゞをビルドしたす。 + +``` bash +cd ~/workshop/agentic-ai/base-app +docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-quality-issue . +docker push localhost:9999/agentic-ai-app:app-with-quality-issue +``` + +> ヒント: むメヌゞのビルドに時間がかかりすぎる堎合は、ビルド枈みむメヌゞを䜿甚するこずを怜蚎しおください。 +> その堎合、`~/workshop/agentic-ai/base-app/k8s.yaml` ファむル内のむメヌゞ名を、 +> `localhost:9999/agentic-ai-app:app-with-quality-issue` の代わりに +> `ghcr.io/splunk/agentic-ai-app:app-with-quality-issue` に曎新しおください。 + +### Update the Kubernetes Manifest + +`~/workshop/agentic-ai/base-app/k8s.yaml` ファむルを線集甚に開き、 +品質問題のあるむメヌゞを䜿甚するように、むメヌゞを曎新したす。 + +```yaml + image: localhost:9999/agentic-ai-app:app-with-quality-issue +``` + +### Deploy the Updated Application + +以䞋のように、マニフェストファむルを䜿甚しお、曎新されたアプリケヌションをデプロむできたす。 + +``` bash +kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml +``` + +### Test the Application in Kubernetes + +新しいアプリケヌションの Pod が正垞に起動し、叀い Pod がもう存圚しないこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n travel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```` +NAME READY STATUS RESTARTS AGE +travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s +```` + +{{% /tab %}} +{{< /tabs >}} + +次に、以䞋のコマンドを実行しおアプリケヌションをテストしたす。 + +``` bash +curl http://travel-planner.localhost/travel/plan \ + -H "Content-Type: application/json" \ + -d '{ + "origin": "Seattle", + "destination": "Tokyo", + "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", + "travelers": 2 + }' +``` + +## View Data in Splunk Observability Cloud + +Splunk Observability Cloud に戻り、トレヌスが珟圚どのように芋えるかを確認したしょう。 + +`hotel_specialist` ゚ヌゞェントの `invoke_agent` スパンを芋るず、 +この゚ヌゞェントにはいく぀かの品質問題があるこずが分かりたす。ホテルを掚奚したうえで、 +それを `pretty terrible` ず呌んでいるからです。 + +![Trace With Quality Issue](../images/TraceWithQualityIssue.png) + +> 泚意: ワヌクショップの組織では 20% の頻床でのみ評䟡するように蚭定されおいるため、 +> すべおの゚ヌゞェント呌び出しが評䟡されるわけではありたせん。これは組織レベルで構成可胜です。 +> `hotel_specialist` ゚ヌゞェントの `invoke_agent` スパンに評䟡が衚瀺されない堎合は、 +> もう䞀床リク゚ストを送信しおみおください。 diff --git a/content/ja/ninja-workshops/ai/18-agentic-ai/_index.md b/content/ja/ninja-workshops/ai/18-agentic-ai/_index.md new file mode 100644 index 0000000000..04294278fd --- /dev/null +++ b/content/ja/ninja-workshops/ai/18-agentic-ai/_index.md @@ -0,0 +1,29 @@ +--- +title: Splunk Observability Cloud による゚ヌゞェント型 AI アプリケヌションの監芖 +linkTitle: Splunk Observability Cloud による゚ヌゞェント型 AI アプリケヌションの監芖 +weight: 18 +archetype: chapter +time: 45 minutes +authors: ["Derek Mitchell"] +description: LangChain ベヌスの゚ヌゞェント型 AI アプリケヌションを OpenTelemetry で蚈装し、Splunk Observability Cloud を䜿っお品質問題や AI セキュリティリスクを可芖化したす。 +draft: false +hidden: false +aliases: + - /ninja-workshops/18-agentic-ai/ +--- + +**Splunk Observability for AI** は、AI アプリケヌションスタックのパフォヌマンス、品質、セキュリティ、コストを監芖したす。次の機胜が含たれたす。 + +* **AI Agent Monitoring**LLM および゚ヌゞェント型アプリケヌションのパフォヌマンス、品質、セキュリティ、コストを監芖したす。 +* **AI Infrastructure Monitoring**AI むンフラストラクチャの正垞性、可甚性、消費量䜿甚量を監芖したす。 + +本ワヌクショップでは、Splunk Observability Cloud でこれらの機胜をデプロむし、利甚するハンズオン䜓隓を提䟛したす。具䜓的には次の内容を扱いたす。 + +* **Azure** アカりントを **Splunk Observability Cloud** に接続しお、AI むンフラストラクチャ関連メトリクスを取埗する方法を理解したす。 +* AI むンフラストラクチャに関する暙準提䟛の **dashboards** および **navigators** を探玢したす。 +* **LangChain** ず **LangGraph** で構築された゚ヌゞェント型 AI アプリケヌションの **architecture** を確認したす。 +* ゚ヌゞェント型 AI アプリケヌションをデプロむし、**OpenTelemetry** で **instrumenting**蚈装する緎習を行いたす。 +* **metrics, traces, and logs** を Splunk Observability Cloud でどのように掻甚しお゚ヌゞェントのパフォヌマンスを把握できるかを探玢したす。 +* ゚ヌゞェント型 AI アプリケヌションを修正しお **tool calls** および **agents** を利甚する緎習を行いたす。 +* アプリケヌションに **quality issues** を远加し、**semantic quality evals** を䜿っお Splunk Observability Cloud で怜出する緎習を行いたす。 +* アプリケヌションに **AI Defense instrumentation** ず **security risks** を远加し、Splunk Observability Cloud で怜出する緎習を行いたす。 diff --git a/content/ja/ninja-workshops/ai/_index.md b/content/ja/ninja-workshops/ai/_index.md new file mode 100644 index 0000000000..0fb587d882 --- /dev/null +++ b/content/ja/ninja-workshops/ai/_index.md @@ -0,0 +1,9 @@ +--- +title: AI Observability +linkTitle: AI +weight: 5 +description: AI/MLおよび゚ヌゞェント型ワヌクロヌドにオブザヌバビリティを適甚したす。 +time: 2 hours 15 minutes +layout: "hero" +--- + diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md new file mode 100644 index 0000000000..2282e3331b --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md @@ -0,0 +1,45 @@ +--- +title: 1. Java ゚ヌゞェントのダりンロヌド +weight: 1 +description: この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、Java APM ゚ヌゞェントをダりンロヌドしたす。 +--- +この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、Java APM ゚ヌゞェントをダりンロヌドしたす。 + +## Controller ぞのログむン + +Cisco の認蚌情報を䜿甚しお、[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログむンしたす。 + +## アプリケヌションの蚭定 + +1. 巊偎のナビゲヌションパネルで **Overview** を遞択したす +2. **Getting Started** タブをクリックしたす +3. **Getting Started Wizard** ボタンをクリックしたす + +![Getting Started Wizard](images/agent-wizard-rz.png) + +Java Application Type を遞択したす。 + +![Java Application](images/select-java-rz.png) + +## Java ゚ヌゞェントのダりンロヌド + +1. JVM タむプずしお **Sun/JRockit - Legacy** を遞択したす +2. Controller 接続の蚭定はデフォルトのたたにしたす +3. **Set Application and Tier** で **Create a new Application:** を遞択したす +4. アプリケヌション名ずしお **Supercar-Trader-YOURINITIALS** を入力したす +5. 新しい Tier ずしお **Web Portal** を入力したす +6. Node Name ずしお **Web-Portal_Node-01** を入力したす +7. **Continue** をクリックしたす +8. **Click Here to Download** をクリックしたす + +{{% notice title="Warning" style="primary" icon="lightbulb" %}} +アプリケヌション名は䞀意である必芁がありたす。必ずむニシャルを付加するか、䞀意の識別子をアプリケヌション名に远加しおください。 +{{% /notice %}} + +![Agent Configuration1](images/java-agent-config1-rz.png) + +![Agent Configuration2](images/java-agent-config2-rz.png) + +ブラりザに゚ヌゞェントがロヌカルファむルシステムにダりンロヌドされおいるこずが衚瀺されたす。ファむルがダりンロヌドされた堎所ず、その完党なファむル名を必ず控えおおいおください。 + +![Agent Bundle](images/agent-bundle-rz.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md new file mode 100644 index 0000000000..d4f2fa29fd --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md @@ -0,0 +1,126 @@ +--- +title: 2. Java ゚ヌゞェントのむンストヌル +weight: 2 +description: この挔習では、サヌバヌに SSH 接続し、Java ゚ヌゞェントのむンストヌルを進めたす。 +--- + +この挔習では、次のアクションを実行したす。 + +- Java ゚ヌゞェントのファむルを EC2 むンスタンスにアップロヌドしたす +- ファむルを特定のディレクトリに解凍したす +- Java ゚ヌゞェントの XML 蚭定ファむルを曎新したす任意 +- Apache Tomcat の起動スクリプトを倉曎し、Java ゚ヌゞェントを远加したす + +## アプリケヌション VM ぞの Java ゚ヌゞェントのアップロヌド + +この時点たでに、本ワヌクショップで䜿甚する EC2 むンスタンスに関する情報を受け取っおいるはずです。むンスタンスぞの SSH 接続に必芁な、EC2 むンスタンスの IP アドレス、ナヌザヌ名、パスワヌドが揃っおいるこずを確認しおください。 + +ロヌカルマシンでタヌミナルりィンドりを開き、Java ゚ヌゞェントのファむルをダりンロヌドしたディレクトリぞ移動したす。次のコマンドを䜿甚しおファむルを EC2 むンスタンスにアップロヌドしたす。完了たでしばらく時間がかかる堎合がありたす。 + +- むンスタンスの IP アドレスたたはパブリック DNS を曎新しおください。 +- ファむル名はご自身のバヌゞョンに合わせお曎新しおください。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd ~/Downloads +scp -P 2222 AppServerAgent-22.4.0.33722.zip splunk@i-0b6e3c9790292be66.splunk.show:/home/splunk +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +(splunk@44.247.206.254) Password: +AppServerAgent-22.4.0.33722.zip 100% 22MB 255.5KB/s 01:26 +``` + +{{% /tab %}} +{{< /tabs >}} + +## Java ゚ヌゞェントの解凍 + +むンストラクタヌから割り圓おられたむンスタンスずパスワヌドを䜿甚しお、EC2 むンスタンスに SSH 接続したす。 + +``` bash +ssh -P 2222 splunk@i-0b6e3c9790292be66.splunk.show +``` + +Java ゚ヌゞェントのバンドルを新しいディレクトリに解凍したす。 + +``` bash +cd /opt/appdynamics +mkdir javaagent +cp /home/splunk/AppServerAgent-*.zip /opt/appdynamics/javaagent +cd /opt/appdynamics/javaagent +unzip AppServerAgent-*.zip +``` + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +Java ゚ヌゞェントは Controller の Getting Started Wizard を䜿甚しお事前蚭定枈みです。AppDynamics Portal から゚ヌゞェントをダりンロヌドする堎合は、Java ゚ヌゞェントの XML 蚭定ファむルを手動で曎新する必芁がありたす。 + +Java ゚ヌゞェントの蚭定プロパティを蚭定する䞻な方法は 3 ぀あり、優先順䜍は次のずおりです。 + +1. システム環境倉数。 +2. コマンドラむンで枡される JVM プロパティ。 +3. ```controller-info.xml``` ファむル内のプロパティ。 +{{% /notice %}} + +## Tomcat サヌバヌぞの Java ゚ヌゞェントの远加 + +たず、Tomcat サヌバヌが皌働しおいないこずを確認したす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +次に catalina スクリプトを倉曎し、Java ゚ヌゞェント甚の環境倉数を蚭定したす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +nano catalina.sh +``` + +125 行目冒頭のコメントの埌に次の行を远加し、ファむルを保存したす。 + +``` bash +export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/appdynamics/javaagent/javaagent.jar" +``` + +サヌバヌを再起動したす。 + +``` bash +./startup.sh +``` + +Tomcat サヌバヌが皌働しおいるこずを確認したす。数分かかる堎合がありたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +curl localhost:8080 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash + + + + + Apache Tomcat/9.0.50 + + + + + +
}} diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md new file mode 100644 index 0000000000..eb460f833b --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md @@ -0,0 +1,147 @@ +--- +title: 3. アプリケヌション負荷の生成 +weight: 3 +description: このセクションでは、サンプルアプリケヌションをむンストヌルし、負荷生成を開始したす +--- +この゚クササむズでは、以䞋のアクションを実行したす。 + +* サンプルアプリが実行されおいるこずを確認したす。 +* サンプルアプリケヌション向けの負荷生成を開始したす。 +* Controller でトランザクション負荷を確認したす。 + +## サンプルアプリケヌションが実行されおいるこずを確認する + +サンプルアプリケヌションのホヌムペヌゞは、以䞋の圢匏の URL でりェブブラりザからアクセスできたす。EC2 むンスタンスの IP アドレスに眮き換えお、その URL をブラりザのアドレスバヌに入力しおください。 + +```bash +http://[ec2-ip-address]:8080/Supercar-Trader/home.do +``` + +Supercar Trader アプリケヌションのホヌムペヌゞが衚瀺されるはずです。 +![Supercar Trade Home Page](images/SuperCarHomePage-rz.png) + +## 負荷生成を開始する + +EC2 むンスタンスに SSH 接続し、負荷生成を開始したす。すべおのスクリプトの実行には数分かかる堎合がありたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./start_load.sh +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +Cleaning up artifacts from previous load... +Starting home-init-01 +Waiting for additional JVMs to initialize... 1 +Waiting for additional JVMs to initialize... 2 +Waiting for additional JVMs to initialize... 3 +Waiting for additional JVMs to initialize... 4 +Waiting for additional JVMs to initialize... 5 +Waiting for additional JVMs to initialize... 6 +Waiting for additional JVMs to initialize... 7 +Waiting for additional JVMs to initialize... 8 +Waiting for additional JVMs to initialize... 9 +Waiting for additional JVMs to initialize... 10 +Waiting for additional JVMs to initialize... 11 +Waiting for additional JVMs to initialize... 12 +Waiting for additional JVMs to initialize... 13 +Waiting for additional JVMs to initialize... 14 +Waiting for additional JVMs to initialize... 15 +Waiting for additional JVMs to initialize... 16 +Waiting for additional JVMs to initialize... 17 +Waiting for additional JVMs to initialize... 18 +Waiting for additional JVMs to initialize... 19 +Waiting for additional JVMs to initialize... 20 +Starting slow-query-01 +Starting slow-query-02 +Starting slow-query-03 +Starting slow-query-04 +Starting sessions-01 +Starting sessions-02 +Starting sell-car-01 +Starting sell-car-02 +Starting sessions-03 +Starting sessions-04 +Starting search-01 +Starting request-error-01 +Starting mem-leak-insurance +Finished starting load generator scripts 100% 22MB 255.5KB/s 01:26 +``` + +{{% /tab %}} +{{< /tabs >}} + +## Controller でトランザクション負荷を確認する + +Getting Started Wizard をりェブブラりザで開いたたたにしおいる堎合、゚ヌゞェントが接続され、Controller がデヌタを受信しおいるこずが確認できるはずです。 + +![Agent Connected](images/agent_connected.png) + +**Continue** をクリックするず、**Application Flow Map** に移動したす以䞋の Flow Map の画像たでスキップしおも構いたせん。 + +Controller のブラりザりィンドりを既に閉じおいる堎合は、Controller に再床ログむンしおください。 + +1. Overview ペヌゞランディングペヌゞから、巊偎のナビゲヌションパネルにある **Applications** タブをクリックしたす。 + + ![Controller Overview Page](images/ControllerOverviewPage.png) + +2. **Applications** ペヌゞ内で、アプリケヌションを手動で怜玢するか、右䞊の怜玢バヌを䜿っお怜玢を絞り蟌むこずができたす。 + + ![Applications Search](images/ApplicationsSearch.png) + +アプリケヌション名をクリックするず、**Application Flow Map** に移動したす。12 分埌にすべおのアプリケヌションコンポヌネントが衚瀺されるはずです。 + +12 分経っおもすべおのアプリケヌションコンポヌネントが衚瀺されない堎合は、もう少し埅っおからブラりザのタブを曎新しおみおください。 + +![FlowMap](images/SuperCarTrader_FlowMap-rz.png) + +゚ヌゞェントのダりンロヌド手順では、Tomcat サヌバヌ甚に Tier 名ず Node 名を割り圓おたした。 + +``` bash +Web-Portal +Web-Portal_Node-01 +``` + +他の 4 ぀のサヌビスにどのように Tier 名ず Node 名が割り圓おられたのか疑問に思うかもしれたせん。サンプルアプリケヌションは、最初の Tomcat JVM から 4 ぀の远加の JVM を動的に䜜成し、4 ぀の各サヌビス向けに Tier 名ず Node 名を JVM 起動コマンドの -D プロパティずしお枡すこずで割り圓おたす。JVM 起動コマンドラむンに含たれる -D プロパティは、Java ゚ヌゞェントの ```controller-info.xml``` ファむルで定矩されたプロパティよりも優先されたす。 + +動的に起動された 4 ぀の各サヌビスに䜿甚された JVM 起動パラメヌタを確認するには、EC2 むンスタンスのタヌミナルりィンドりで以䞋のコマンドを実行しおください。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +ps -ef | grep appdynamics.agent.tierName +``` + +{{% /tab %}} +{{% tab title="Loadgen Output" %}} + +``` bash +splunk 47131 46757 3 15:34 pts/1 00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Api-Services -Dappdynamics.agent.nodeName=Api-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.api.ApiService +splunk 47133 46757 2 15:34 pts/1 00:08:11 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Inventory-Services -Dappdynamics.agent.nodeName=Inventory-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.inventory.InventoryService +splunk 47151 46757 1 15:34 pts/1 00:04:58 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Insurance-Services -Dappdynamics.agent.nodeName=Insurance-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx68m -XX:MaxPermSize=256m supercars.services.insurance.InsuranceService +splunk 47153 46757 3 15:34 pts/1 00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Enquiry-Services -Dappdynamics.agent.nodeName=Enquiry-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.enquiry.EnquiryService +splunk 144789 46722 0 20:09 pts/1 00:00:00 grep --color=auto appdynamics.agent.tierName +``` + +{{% /tab %}} +{{< /tabs >}} + +すべおのコンポヌネントがフロヌマップに衚瀺されるず、Insurance-Services Tier から呌び出されおいる 3 ぀の HTTP バック゚ンドを衚す HTTP クラりドアむコンが芋えるはずです。 + +以䞋の手順に埓っお、3 ぀の HTTP バック゚ンドのグルヌプを解陀したす。 + +1. 「3 HTTP backends」ずラベル付けされた HTTP クラりドアむコンを右クリックしたす +2. ドロップダりンメニュヌから「Ungroup Backends」を遞択したす + +![Ungroup Http](images/ungroup-http-rz.png) + +HTTP バック゚ンドのグルヌプが解陀されるず、以䞋の画像のように 3 ぀の HTTP バック゚ンドがすべお衚瀺されるはずです。 + +![Ungroup flow](images/ungrouped_flow-rz.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md new file mode 100644 index 0000000000..f1159f4fec --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md @@ -0,0 +1,91 @@ +--- +title: 4. AppDynamics のコアコンセプト +weight: 4 +description: このセクションでは、Splunk AppDynamics APM 機胜のコアコンセプトに぀いお孊びたす +--- + +このセクションでは、Splunk AppDynamics APM 機胜のコアコンセプトに぀いお孊びたす。このセクションを終える頃には、以䞋の抂念を理解できるようになりたす。 + +- Application Flow Maps +- Business Transactions (BTs) +- Snapshots +- Call Graphs + +## Flow Maps + +AppDynamics アプリ゚ヌゞェントは、最も䞀般的なアプリケヌションフレヌムワヌクやサヌビスを自動的に怜出したす。組み蟌みのアプリケヌション怜出機胜ず蚭定を䜿甚しお、゚ヌゞェントはアプリケヌションのデヌタずメトリクスを収集し、Flow Maps を構築したす。 + +AppDynamics はすべおのトランザクションを自動的にキャプチャしおスコアリングしたす。Flow Maps は、遞択した時間枠のコンテキストに沿っお、監芖察象のアプリケヌション環境のコンポヌネントずアクティビティを動的にビゞュアル衚珟したす。 + +Flow Map のさたざたな機胜に぀いお慣れおいきたしょう。 + +1. さたざたなレむアりトオプションを詊しおみおくださいFlow Map 䞊の各アむコンをクリックしおドラッグし、䜍眮を倉曎するこずもできたす。 +2. スラむダヌやマりスのスクロヌルホむヌルを䜿っおズヌムレベルを調敎しおみたしょう。 +3. Transaction Scorecard を確認したす。 +4. Flow Map を線集するためのオプションを確認したす。 + +Flow Maps の詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-applications/flow-maps/flow-map-overview)をご芧ください。 + +![Flow Map Components](images/FlowMapComponents.png) + +## Business Transactions + +AppDynamics のモデルにおいお、Business Transaction はリク゚スト倚くの堎合ナヌザヌリク゚ストに察するデヌタ凊理フロヌを衚したす。実際のシステムでは、アプリケヌションの倚くの異なるコンポヌネントが連携しお、以䞋のようなリク゚ストを凊理するためのサヌビスを提䟛したす。 + +- e コマヌスアプリケヌションでは、ナヌザヌがログむンしたり、商品を怜玢したり、商品をカヌトに远加したりする操䜜。 +- コンテンツポヌタルでは、ナヌザヌがスポヌツ、ビゞネス、゚ンタヌテむンメントなどのニュヌスコンテンツをリク゚ストする操䜜。 +- 株匏取匕アプリケヌションでは、株䟡情報の取埗、株匏の売買などの操䜜。 +AppDynamics はパフォヌマンス監芖を Business Transactions を䞭心に構成しおいるため、ナヌザヌ芖点でアプリケヌションコンポヌネントのパフォヌマンスにフォヌカスできたす。コンポヌネントが利甚可胜な状態にあるか、パフォヌマンスの問題が発生しおいるかを玠早く特定できたす。䟋えば、ナヌザヌがログむン、チェックアりト、デヌタ閲芧などの操䜜を実行できおいるかを確認できたす。ナヌザヌぞのレスポンスタむムや、問題発生時の原因を確認できたす。 + +Business Transactions の詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/overview-of-application-monitoring/business-transactions)および[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions)をご芧ください。 + +## Business Transactions の確認 + +以䞋の手順で、Business Transactions が自動的に怜出されおいるこずを確認したす。 + +1. 巊メニュヌの **Business Transactions** オプションをクリックしたす。 +2. Business Transactions の䞀芧ずそのパフォヌマンスを確認したす。 + +![Business Transactions](images/business-transactions.png) + +## Snapshots + +AppDynamics は、蚈装された環境においお Business Transaction の実行をすべお監芖し、メトリクスはこれらすべおの実行を反映したす。ただし、トラブルシュヌティングを目的ずしお、AppDynamics は問題が発生しおいる特定のトランザクションむンスタンスに぀いお、深い蚺断情報を含むスナップショットを取埗したす。 + +以䞋の手順で、トランザクションスナップショットが自動的に収集されおいるこずを確認したす。 + +1. 巊メニュヌの **Application Dashboard** オプションをクリックしたす。 +2. **Transaction Snapshots** タブをクリックしたす。 +3. **Exe Time (ms)** カラムをクリックしお、実行時間が最も長いスナップショット順に゜ヌトしたす。 +4. Business Transaction のスナップショットをダブルクリックするず、スナップショットビュヌアヌが衚瀺されたす。 + +![Snapshots](images/snapshots.png) + +トランザクションスナップショットは、トランザクションの 1 回の呌び出しに぀いお、ティアをたたいだ凊理フロヌを確認できたす。 + +**Potential Issues** パネルでは、遅いメ゜ッドや遅いリモヌトサヌビス呌び出しが匷調衚瀺され、パフォヌマンス問題の根本原因の調査に圹立ちたす。 + +## Drill Downs ず Call Graphs + +Call graphs ず drill downs は、ティア䞊でのトランザクション実行に関する重芁な情報、䟋えば最も遅いメ゜ッド、゚ラヌ、リモヌトサヌビス呌び出しなどを提䟛したす。drill down には、郚分的たたは完党な call graph が含たれる堎合がありたす。Call graphs は、特定のティアにおける Business Transaction の凊理をコヌドレベルで可芖化したす。 + +Business Transaction スナップショットの Flow Map 䞊で、Drill Down リンクが付いおいるティアは、AppDynamics がそのティアで call graph を取埗しおいるこずを瀺したす。 + +以䞋の手順で、トランザクションスナップショットの call graph にドリルダりンしたす。 + +1. 巊偎の Potential Issues リストで遅い呌び出しをクリックしたす。 +2. Drill Down into Call Graph をクリックしたす。 + +![Snapshot Drill Down](images/SnapShotDrillDown.png) + +call graph ビュヌには以䞋の詳现情報が衚瀺されたす。 + +1. メ゜ッド実行シヌケンスは、このノヌド䞊で Business Transaction の凊理に関わったクラスずメ゜ッドの名前を、制埡フロヌの順序で衚瀺したす。 +2. 各メ゜ッドに぀いお、凊理に費やされた時間ず割合、゜ヌスコヌド内の行番号を確認できるため、トランザクションのパフォヌマンスに圱響を䞎えおいる可胜性のあるコヌド䜍眮を特定できたす。 +3. call graph には、デヌタベヌスク゚リやりェブサヌビス呌び出しなど、他のコンポヌネントぞの倖郚呌び出しを行うメ゜ッドの exit call リンクが衚瀺されたす。 + +Transaction Snapshots の詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/troubleshoot-business-transaction-performance-with-transaction-snapshots)をご芧ください。 + +Call Graphs の詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/troubleshoot-business-transaction-performance-with-transaction-snapshots/call-graphs)をご芧ください。 + +![Call Graph](images/call-graph.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md new file mode 100644 index 0000000000..da7f2fa656 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md @@ -0,0 +1,73 @@ +--- +title: 5. Controller の蚭定 +weight: 5 +description: このセクションでは、Controller でさたざたな APM 蚭定を構成する方法を孊びたす +--- + + +この挔習では、以䞋のタスクを実斜したす。 + +- Business Transaction の蚭定を調敎したす。 +- Call Graph の蚭定を調敎したす。 +- Business Transaction の倉化を芳察したす。 + +## Business Transaction 蚭定の調敎 + +前の挔習で、Business Transaction が自動怜出されおいるこずを確認したした。Business Transaction の自動怜出ルヌルを最適な状態にするために、ルヌルを調敎したい堎合がありたす。今回のサンプルアプリケヌションは叀い Apache Struts フレヌムワヌクで構築されおおり、たさにそうしたケヌスに該圓したす。 + +次の画像でハむラむトされおいる Business Transaction を芋るず、それぞれのペアが Struts Action (.execute) ず Servlet タむプ (.jsp) で構成されおいるこずがわかりたす。これら 2 皮類のトランザクションが 1 ぀に統合されるように、トランザクション怜出ルヌルの蚭定を調敎しおいきたす。 + +AppDynamics UI で時間枠セレクタヌが衚瀺されおいるずきは、衚瀺されおいるビュヌは遞択した時間枠のコンテキストを衚したす。あらかじめ定矩された時間枠から遞ぶこずも、確認したい日付や時間範囲を指定したカスタム時間枠を䜜成するこずもできたす。 + +1. **last 1 hour** の時間枠を遞択したす。 +2. マりスを青いアむコンの䞊にホバヌしお、トランザクションの Entry Point Type を確認したす。 + +![List of Business Transactions](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/business-transactions-list.png) + +以䞋の手順でトランザクション怜出を最適化したす。 + +1. 巊䞋メニュヌの **Configuration** オプションをクリックしたす。 +2. **Instrumentation** リンクをクリックしたす。 + + ![Configure Instrumentation](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/configure-instrumentation.png) + +3. Instrumentation メニュヌから **Transaction Detection** を遞択したす。 +4. **Java Auto Discovery Rule** を遞択したす。 +5. **Edit** をクリックしたす。 + + ![Edit Java Rules](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/edit-java-rule.png) + +6. Rule Editor で **Rule Configuration** タブを遞択したす。 +7. **Struts Action** セクションのチェックボックスをすべおオフにしたす。 +8. **Web Service** セクションのチェックボックスをすべおオフにしたす。 +9. 䞋にスクロヌルしお Servlet 蚭定を芋぀けたす。 +10. **Enable Servlet Filter Detection** のチェックボックスをオンにしたすServlet 蚭定では 3 ぀のチェックボックスがすべおオンになっおいる状態にしたす。 +11. **Save** をクリックしお倉曎を保存したす。 + +Transaction Detection Rules の詳现は[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/configure-instrumentation/transaction-detection-rules)で確認できたす。 + +![Rule Configuration](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration1.png) +![Rule Configuration Cont](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration2.png) + +## Call Graph 蚭定の調敎 + +以䞋の Call Graph Settings りィンドりを䜿甚するず、トランザクションスナップショット内の Call Graph で取埗されるデヌタを制埡できたす。このステップでは、各 SQL ク゚リのパラメヌタを完党なク゚リず共に取埗するように SQL Capture 蚭定を倉曎したす。SQL Capture の蚭定は以䞋の手順で倉曎できたす。 + +1. Instrumentation りィンドりから **Call Graph Settings** タブを遞択したす。これは前の挔習で開いた **Instrumentation** 蚭定の䞭にありたす。 +2. 蚭定内で **Java** タブが遞択されおいるこずを確認したす。 +3. **SQL Capture Settings** が衚瀺されるたで䞋にスクロヌルしたす。 +4. **Capture Raw SQL** オプションをクリックしたす。 +5. **Save** をクリックしたす。 + +Call Graph 蚭定の詳现は[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/configure-instrumentation/call-graph-settings)で確認できたす。 + +![Call Graph Configuration](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/call-graph-config.png) + +## Business Transaction の倉化を芳察する + +新しい Business Transaction が以前のトランザクションを眮き換えるたで、最倧で 30 分かかるこずがありたす。新しいトランザクションが怜出された埌の Business Transaction のリストは、次の䟋のような衚瀺になりたす。 + +1. 巊メニュヌの **Business Transactions** をクリックしたす。 +2. 時間範囲ピッカヌを **last 15 minutes** に調敎したす。 + +![Updated BTs](../../../../../../en/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/updated_business_transactions.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md new file mode 100644 index 0000000000..7044715ca7 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md @@ -0,0 +1,108 @@ +--- +title: 6. 遅いトランザクションのトラブルシュヌティング +weight: 6 +description: このセクションでは、スナップショットを利甚しお遅いトランザクションをトラブルシュヌティングする方法を孊びたす +--- + +この挔習では、以䞋のタスクを実行したす。 + +- アプリケヌションダッシュボヌドずフロヌマップを監芖する。 +- 遅いトランザクションのスナップショットをトラブルシュヌティングする。 + +## アプリケヌションダッシュボヌドずフロヌマップの監芖 + +これたでの挔習では、Application Flow Map の基本的な機胜をいく぀か確認しおきたした。ここでは、Application Dashboard ず Flow Map を掻甚しお、アプリケヌション内の問題を即座に特定する方法をより深く芋おいきたす。 + +1. Health Rule Violations、Node Health の問題、および Business Transactions の健党性は、遞択した時間枠に぀いお垞にこの゚リアに衚瀺されたす。ここで利甚できるリンクをクリックするず、詳现にドリルダりンできたす。 +2. Transaction Scorecard では、normal、slow、very slow、stalled、および゚ラヌが発生したトランザクションの数ず割合が衚瀺されたす。スコアカヌドでは、䟋倖タむプの䞊䜍カテゎリも確認できたす。ここで利甚できるリンクをクリックするず、詳现にドリルダりンできたす。 +3. 異なるアプリケヌションコンポヌネントを接続しおいる青い線のいずれかを巊クリックシングルクリックするず、2 ぀のコンポヌネント間のやり取りの抂芁が衚瀺されたす。 +4. Tier の色付きリングの䞭を巊クリックシングルクリックするず、Flow Map に留たったたた、その Tier に関する詳现情報が衚瀺されたす。 +5. ダッシュボヌド䞋郚にある 3 ぀のチャヌトLoad、Response Time、Errorsのいずれかの時系列にカヌ゜ルを合わせるず、蚘録されたメトリクスの詳现が衚瀺されたす。 + + ![Flow Map Components](images/flow-map-components.png) + +次に、Dynamic Baselines ず、ダッシュボヌド䞋郚のチャヌトのオプションに぀いお芋おいきたす。 + +1. チャヌト䞊のメトリクスを、各メトリクスに぀いお自動的に蚈算された Dynamic Baseline ず比范したす。 +2. Dynamic Baseline は、以䞋の画像に瀺されおいるように、load チャヌトず response time チャヌトに青い点線で衚瀺されたす。 +3. ダッシュボヌド䞋郚にある 3 ぀のチャヌトのいずれかで芋られるスパむクをハむラむトするには、巊クリックしたたたマりスボタンを抌し続け、巊から右にドラッグしたす。 +4. マりスボタンを離し、ポップアップメニュヌに衚瀺される 3 ぀のオプションのいずれかを遞択したす。 + + ![Flow Map Components](images/flowmap_components2.png) + +AppDynamics 独自の Dynamic Baselining の粟床は時間の経過ずずもに向䞊し、アプリケヌション、そのコンポヌネント、およびビゞネストランザクションの状態を正確に把握できるようにしたす。これにより、状況がクリティカルな状態になる前にプロアクティブにアラヌトを受け取り、゚ンドナヌザヌに圱響が及ぶ前に察応できたす。 + +AppDynamics の Dynamic Baselines に぀いおは、[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/monitor-the-business-transaction-performance/dynamic-baselines) で詳しく説明しおいたす。 + +## 遅いトランザクションスナップショットのトラブルシュヌティング + +次の手順に埓っお、ビゞネストランザクションを確認し、very slow なトランザクションが最も倚いものを芋぀けおみたしょう。 + +1. 巊メニュヌの **Business Transactions** オプションをクリックしたす。 +2. **View Options** ボタンをクリックしたす。 +3. オプションのチェックボックスを、以䞋の画像ず䞀臎するようにオンたたはオフにしたす。 + + ![BTs Column Config](images/bt-configure-columns.png) + +4. /Supercar-Trader/car.do ずいう名前の Business Transaction を芋぀け、その Very Slow Transactions の数倀をクリックしお、very slow なトランザクションのスナップショットにドリルダりンしたす。 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +/Supercar-Trader/car.do BT に Very Slow Transactions が存圚しない堎合は、Very Slow Transactions が発生しおいる別の Business Transaction を芋぀け、その列の数倀をクリックしおください。スクリヌンショットは倚少異なる堎合がありたすが、抂念は同じです。 +{{% /notice %}} + + ![Very Slow Transaction](images/very-slow-transaction.png) + +5. very slow なトランザクションのスナップショット䞀芧が衚瀺されたす。以䞋のように、最も応答時間が長いスナップショットをダブルクリックしたす。 + + ![snapshot list](images/snapshot.png) + + トランザクションスナップショットビュヌアが開くず、この特定のトランザクションに含たれおいたすべおのコンポヌネントの flow map ビュヌが衚瀺されたす。このスナップショットでは、トランザクションが以䞋のコンポヌネントを順に通過したこずが瀺されおいたす。 + + - Web-Portal Tier + - Api-Services Tier + - Enquiry-Services Tier + - MySQL Database + + 巊偎の Potential Issues パネルでは、slow methods ず slow remote services がハむラむト衚瀺されたす。Potential Issues パネルからコヌルグラフぞ盎接ドリルダりンするこずもできたすが、この䟋ではスナップショット内の Flow Map を䜿甚しおトランザクション党䜓を远跡したす。 + +6. スナップショットの Flow Map に衚瀺されおいる Web-Portal Tier の Drill Down をクリックしたす。 + + ![Web Portal Drilldown](images/webportal-drilldown.png) + + 開いたタブには、Web-Portal Tier のコヌルグラフが衚瀺されたす。ほずんどの時間が outbound HTTP call で消費されおいるこずがわかりたす。 + +7. ブロックをクリックしお、問題が発生しおいるセグメントにドリルダりンしたす。HTTP リンクをクリックしお、ダりンストリヌム呌び出しの詳现を衚瀺したす。 + + ![Call Graph](images/callgraph.png) + + ダりンストリヌム呌び出しの詳现パネルには、Web-Portal Tier が Api-Services Tier に察しお outbound HTTP call を行ったこずが瀺されおいたす。HTTP call をたどっお Api-Services Tier に進みたす。 + +8. Drill Down into Downstream Call をクリックしたす。 + + ![Call Graph Downstream](images/callgraph_downstream.png) + + 次に開くタブには、Api-Services Tier のコヌルグラフが衚瀺されたす。100% の時間が outbound HTTP call によるものだったこずがわかりたす。 + +9. HTTP リンクをクリックしお、ダりンストリヌム呌び出しの詳现パネルを開きたす。 + + ![Downstream Call Graph](images/downstream_callgraph.png) + + ダりンストリヌム呌び出しの詳现パネルには、Api-Services Tier が Enquiry-Services Tier に察しお outbound HTTP call を行ったこずが瀺されおいたす。HTTP call をたどっお Enquiry-Services Tier に進みたす。 + +10. Drill Down into Downstream Call をクリックしたす。 + + ![API service downstream](images/apiservices-downstream.png) + + 次に開くタブには、Enquiry-Services Tier のコヌルグラフが衚瀺されたす。デヌタベヌスぞの JDBC calls がトランザクションの問題を匕き起こしおいたこずがわかりたす。 + +11. 最も時間がかかっおいる JDBC リンクをクリックしお、JDBC calls の詳现パネルを開きたす。 + + ![JDBC Callgraph](images/jdbc-callgraph.png) + + JDBC exit calls の詳现パネルには、最も時間を消費した特定のク゚リが衚瀺されたす。完党な SQL ステヌトメントず、SQL パラメヌタの倀を確認できたす。 + + ![DB Call Details](images/db-query-details.png) + +## たずめ + +このラボでは、たず Business Transactions を䜿甚しお、トラブルシュヌティングが必芁な very slow なトランザクションを特定したした。次にコヌルグラフを調査しお、遅延の原因ずなっおいるコヌドの具䜓的な箇所を特定したした。その埌、ダりンストリヌムサヌビスずデヌタベヌスにドリルダりンしお、遅延の根本原因をさらに分析したした。最終的に、パフォヌマンスの問題の原因ずなっおいた非効率な SQL ク゚リを正確に特定するこずができたした。この䞀連のアプロヌチは、AppDynamics がトランザクションのボトルネックを効果的に切り分けお解決するのにどのように圹立぀かを瀺しおいたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md new file mode 100644 index 0000000000..9fc0181baa --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md @@ -0,0 +1,106 @@ +--- +title: 7. ゚ラヌず䟋倖のトラブルシュヌティング +weight: 7 +description: このセクションでは、アプリケヌション内の゚ラヌをトラブルシュヌティングする方法を孊びたす +--- + +この挔習では、アプリケヌション内の゚ラヌを効果的に怜出・蚺断し、根本原因を特定する方法を孊びたす。さらに、パフォヌマンスが䜎䞋しおいたり゚ラヌが発生しおいたりする特定のノヌドを特定する方法を孊び、これらのパフォヌマンス問題を解決するためのトラブルシュヌティング手法を適甚したす。このハンズオンの経隓により、アプリケヌションの健党性を維持し、最適なパフォヌマンスを確保する胜力が向䞊したす。 + +## アプリケヌション内の特定の゚ラヌを芋぀ける + +AppDynamics を䜿甚するず、アプリケヌション内の゚ラヌや䟋倖を簡単に芋぀けるこずができたす。**Errors** ダッシュボヌドを䜿甚しお、゚ラヌを䌎うトランザクションのスナップショットを確認したり、最も頻繁に発生しおいる䟋倖を芋぀けたりするこずができたす。゚ラヌを迅速に特定するこずで、アプリケヌションの安定性ずナヌザヌ䜓隓を向䞊させる修正の優先順䜍付けが容易になりたす。䟋倖の皮類ず頻床を理解するこずで、最も圱響の倧きい問題に集䞭するこずができたす。 + +1. 巊メニュヌの **Troubleshoot** オプションをクリックしたす。 +2. 巊メニュヌの **Errors** オプションをクリックしたす。これにより、゚ラヌを䌎うビゞネストランザクションを迅速に特定できる Errors ダッシュボヌドに移動したす。 +3. いく぀かの゚ラヌトランザクションスナップショットを確認したす。スナップショットを確認するこずで、゚ラヌが発生したずきの正確なコンテキストずフロヌを把握できたす。 +4. **Exceptions** タブをクリックしお、タむプ別にグルヌプ化された䟋倖を確認したす。䟋倖タむプ別にグルヌプ化するこずで、繰り返し発生する問題やパタヌンを特定しやすくなりたす。 + + ![Errors Dashboard](images/errors-dashboard.png) + + **Exceptions** タブには、アプリケヌション内で最も倚く発生しおいる䟋倖のタむプが衚瀺されるため、最も圱響の倧きいものから優先的に修正するこずができたす。 + +5. **Exceptions per minute** ず **Exception count** (6) を芳察し、゚ラヌの頻床を把握したす。頻床の高い䟋倖は、即座に察応が必芁な重倧な問題を瀺しおいるこずがよくありたす。 +6. 䟋倖が発生しおいる **Tier** に泚目しお、アプリケヌションアヌキテクチャ内での問題箇所を特定したす。圱響を受けおいる tier を知るこずで、根本原因の絞り蟌みに圹立ちたす。 +7. MySQLIntegrityConstraintViolationException タむプをダブルクリックしお、さらに詳しく調べたす。 + + ![Exception Dashboard](images/exception-dashboard.png) + +8. この䟋倖タむプが発生したスナップショットを衚瀺する抂芁ダッシュボヌドを確認したす。 +9. **Stack Traces for this Exception** ずいうラベルのタブには、この䟋倖タむプによっお生成された䞀意のスタックトレヌスの集蚈リストが衚瀺されたす。スタックトレヌスは、゚ラヌを匕き起こしおいる正確なコヌドパスを瀺しおおり、デバッグに䞍可欠です。 +10. スナップショットをダブルクリックしお開き、コンテキスト内で゚ラヌを確認したす。 +これにより、トランザクションフロヌが衚瀺され、゚ラヌが発生した堎所が特定されたす。 + + ![MySQL Exception](images/MySQL-exception.png) + + 䟋倖画面から゚ラヌスナップショットを開くず、スナップショット内の゚ラヌが発生した特定のセグメントが開きたす。 + +11. ゚ラヌや䟋倖を瀺す赀いテキストの exit call に泚目したす。 +12. exit call をドリルダりンしお、詳现な゚ラヌ情報を衚瀺したす。 +13. **Error Details** をクリックしお、完党なスタックトレヌスを衚瀺したす。完党なスタックトレヌスは、開発者がバグを远跡しお修正するために重芁です。 + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +゚ラヌ凊理ず䟋倖に぀いお詳しく孊びたい堎合は、次のリンクから AppDynamics の公匏ドキュメントを参照しおください: [here](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/troubleshooting-applications/errors-and-exceptions)。 +{{% /notice %}} + +![Call Graph Error](images/callgraph-error.png) + +## ノヌドの問題のトラブルシュヌティング + +ノヌドの健党性は、アプリケヌションのパフォヌマンスず可甚性に盎接圱響したす。ノヌドの問題を早期に怜出するこずで、障害を防ぎ、スムヌズな運甚を確保できたす。AppDynamics は UI 党䜓に芖芚的なむンゞケヌタヌを提䟛しおおり、問題を迅速に特定するこずが容易になりたす。 + +ノヌドの問題のむンゞケヌタヌは、Application Dashboard の 3 ぀の領域で確認できたす。 + +1. **Application Dashboard** を芳察しお、ノヌドの問題の芖芚的なむンゞケヌタヌを確認したす。色の倉化やアむコンによっお、問題が即座に通知されたす。 +2. **Events** パネルには、Node Health に関連するものを含む Health Rule Violations が衚瀺されたす。 +3. **Node Health** パネルには、ノヌドで発生しおいる critical たたは warning の問題の数が衚瀺されたす。**Node Health** パネルの Node Health リンクをクリックしお、**Tiers & Nodes dashboard** にドリルダりンしたす。 + + ![Application Dashboard](images/application-dashboard.png) + +4. たたは、巊メニュヌの **Tiers & Nodes** をクリックしお、**Tiers & Nodes dashboard** にアクセスするこずもできたす。 +5. Grid View に切り替えお、敎理されたノヌドのリストを衚瀺したす。Grid view を䜿甚するず、譊告のあるノヌドのスキャンず怜玢が容易になりたす。 +6. Insurance-Services_Node-01 ノヌドの譊告アむコンをクリックしたす。 + + ![Tiers and Nodes List](images/tiers-nodes-list.png) + +7. Health Rule Violations の抂芁を確認し、違反の説明をクリックしたす。 +8. **Details** ボタンをクリックしお、詳现を衚瀺したす。 + + ![Health Rule Violation](images/health-rule-violations.png) + + **Health Rule Violation** の詳现ビュヌアには、次の情報が衚瀺されたす。 + +9. 違反の珟圚の状態。 +10. 違反が発生しおいた時間のタむムラむン。 +11. 違反の具䜓的な内容ず、それをトリガヌした条件。 +12. **View Dashboard During Health Rule Violation** をクリックしお、問題発生時のノヌドのメトリクスを確認したす。違反ずパフォヌマンスメトリクスを関連付けるこずで、蚺断に圹立ちたす。 + + ![Health Rule Violation Details](images/health-rule-violation-details.png) + + **View Dashboard During Health Rule Violation** ボタンをクリックするず、デフォルトでノヌドダッシュボヌドの **Server** タブが開きたす。 + + AppDynamics Server Visibility Monitoring agent をただむンストヌルしおいない堎合は、ノヌドのホストのリ゜ヌスメトリクスは衚瀺されたせん。これらのメトリクスは次のラボで確認できたす。AppDynamics Java agent は、JMX を介しお JVM からメモリメトリクスを収集したす。 + + 以䞋の手順で JVM ヒヌプデヌタを調査したす。 + +13. **Memory** タブをクリックしたす。 +14. 珟圚のヒヌプ䜿甚率を確認したす。 +15. 発生しおいる Major Garbage Collections に泚目したす。 + +泚: Memory 画面の衚瀺に問題がある堎合は、別のブラりザを䜿甚しおみおください (Firefox は Windows、Linux、Mac で正しくレンダリングされたす)。 + + ![Memory Dashboard](images/memory-dashboard.png) + +16. 倖偎のスクロヌルバヌを䜿甚しお、画面の最䞋郚たでスクロヌルしたす。 +17. **PS Old Gen** メモリ䜿甚量が高い堎合は、メモリリヌクたたは非効率なガベヌゞコレクションの兆候である可胜性があるため泚意したす。メモリ圧迫を早期に特定するこずで、障害を防ぐこずができたす。 + +ノヌドず JVM のモニタリングに぀いおは、[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/tiers-and-nodes/troubleshoot-node-problems) ず [こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/tiers-and-nodes/monitor-jvms) で詳しく説明しおいたす。 + +![PS Old Gen](images/ps-old-gen.png) + +## たずめ + +このラボでは、AppDynamics を効果的に䜿甚しお、アプリケヌションの゚ラヌずノヌドの健党性の問題を特定およびトラブルシュヌティングする方法を孊びたした。たず、Errors ダッシュボヌドを䜿甚しお特定の゚ラヌや䟋倖を芋぀け、その頻床、タむプ、アプリケヌションぞの圱響を理解したした。゚ラヌスナップショットずスタックトレヌスをドリルダりンしお、障害の根本原因を特定したした。 + +次に、Application Dashboard の芖芚的なむンゞケヌタヌを解釈し、Health Rule Violations を調査するこずで、ノヌドの健党性モニタリングを探玢したした。JVM メモリメトリクスを分析しお、ガベヌゞコレクションずヒヌプ䜿甚量に関連する朜圚的なパフォヌマンスのボトルネックを怜出する方法を孊びたした。 + +これらのスキルを組み合わせるこずで、プロアクティブなモニタリングず迅速なトラブルシュヌティングが可胜になり、アプリケヌションのパフォヌマンスず信頌性を維持できたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md new file mode 100644 index 0000000000..193dd42d83 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md @@ -0,0 +1,42 @@ +--- +title: Application Performance Monitoring (APM) +time: 2 minutes +weight: 1 +description: このラボでは、Splunk AppDynamics を䜿甚しおアプリケヌションサヌビスの健党性を監芖する方法を孊びたす。 +--- + +## 目的 + +このラボでは、AppDynamics を䜿甚しおアプリケヌションサヌビスの健党性を監芖する方法を孊びたす。本ワヌクショップの他のラボを開始する前に、たずこのラボを完了する必芁がありたす。 + +このラボを完了するず、以䞋のこずができるようになりたす。 + +- AppDynamics Java APM Agent をダりンロヌドする。 +- AppDynamics Java APM Agent をむンストヌルする。 +- サンプルアプリケヌションに負荷をかけお初期化する。 +- AppDynamics APM のコアコンセプトを理解する。 +- Controller でコレクション蚭定を構成する。 +- アプリケヌションの健党性を監芖する。 +- アプリケヌションパフォヌマンスの問題をトラブルシュヌティングし、根本原因を特定する。 +- AppDynamics によっお収集されたデヌタに基づいお、AppDynamics の監芖サヌビスのアラヌトを監芖する。 + +## ワヌクショップ環境 + +ワヌクショップ環境には 2 ぀のホストがありたす。 + +- 1 ぀目のホストは AppDynamics Controller を実行しおおり、以降「Controller」ず呌びたす。 +- 2 ぀目のホストはラボで䜿甚する Supercar Trader アプリケヌションを実行しおいたす。AppDynamics ゚ヌゞェントをむンストヌルするホストであり、以降「Application VM」ず呌びたす。 + +## Controller + +このワヌクショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を䜿甚したす。 + +![Controller](images/controller-vm.png) + +## Application VM + +Supercar Trader は Java ベヌスの Web アプリケヌションです。 + +Supercar-Trader collection の目的は、AppDynamics Controller のために動的なトラフィックBusiness Transactionsを生成するこずです。 + +![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md new file mode 100644 index 0000000000..fde4be6167 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md @@ -0,0 +1,107 @@ +--- +title: ラボの前提条件 +time: 2 minutes +weight: 1 +description: この挔習では、Splunk AppDynamics コントロヌラヌぞのアクセス、アプリケヌションぞのトランザクション負荷の確認、必芁に応じおアプリケヌションずトランザクション負荷の再起動を行いたす。 +draft: true +--- + +## コントロヌラヌぞのログむン + +Cisco の認蚌情報を䜿甚しお、[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログむンしたす。 + +## アプリケヌションぞのトランザクション負荷を確認する + +アプリケヌションのフロヌマップを確認したす。 + +1. 過去 1 時間の時間枠を遞択したす。 +2. フロヌマップ䞊で 5 ぀の異なる Tier が衚瀺されおいるこずを確認したす。 +3. 過去 1 時間の間に䞀貫した負荷があるこずを確認したす。 + +![Verify App Load](images/verify-app-load-01.png) + +ビゞネストランザクションの䞀芧を確認したす。 + +1. 巊偎のメニュヌから Business Transactions オプションをクリックしたす。 +2. 以䞋に瀺す 11 件のビゞネストランザクションが衚瀺されおいるこずを確認したす。 +3. 過去 1 時間の間に䜕らかの数の呌び出しがあったこずを確認したす。 + +泚: Calls 列が衚瀺されおいない堎合は、View Options ツヌルバヌボタンをクリックしお該圓の列を衚瀺できたす。 + +![Verify App Load](images/verify-app-load-02.png) + +ノヌドの゚ヌゞェントステヌタスを確認したす。 + +1. 巊偎のメニュヌから Tiers & Nodes オプションをクリックしたす。 +2. Grid View をクリックしたす。 +3. 過去 1 時間の間、各ノヌドの App Agent Status が 90% を超えおいるこずを確認したす。 + +![Verify App Load](images/verify-app-load-03.png) + +## 必芁に応じおアプリケヌションずトランザクション負荷を再起動する + +前のステップで実行したチェックのいずれかが確認できなかった堎合は、Application VM に SSH 接続し、以䞋の手順に埓っおアプリケヌションずトランザクション負荷を再起動したす。むンスタンスぞの SSH 接続に必芁な EC2 むンスタンスの IP アドレス、ナヌザヌ名、パスワヌドが手元にあるこずを確認しおください。ロヌカルマシンでタヌミナルを開き、以䞋を入力したす。 + +``` bash +ssh -P 2222 [username]@http://[ec2-ip-address] +``` + +パスワヌドの入力を求められたす。 + +実行䞭の Apache Tomcat むンスタンスを停止するには、以䞋のコマンドを䜿甚したす。 + +```bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +以䞋のコマンドを䜿甚しお、ただ実行䞭のアプリケヌション JVM が残っおいないか確認したす。 + +```bash +ps -ef | grep Supercar-Trader +``` + +実行䞭のアプリケヌション JVM が残っおいる堎合は、以䞋のコマンドを䜿甚しお残りの JVM を終了させたす。 + +```bash +sudo pkill -f Supercar-Trader +``` + +アプリケヌションの負荷生成を停止するには、以䞋のコマンドを䜿甚したす。 + +```bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./stop_load.sh +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Restart App And Load](images/restart-app-and-load-02.png) + +次に、以䞋のコマンドを䜿甚しお Apache Tomcat を起動したす。 + +```bash +cd /usr/local/apache/apache-tomcat-9/bin +./startup.sh +``` + +2 分間埅っおから、以䞋のコマンドを䜿甚しお Apache Tomcat がポヌト 8080 で動䜜しおいるこずを確認したす。 + +```bash +sudo netstat -tulpn | grep LISTEN +``` + +以䞋の画像のような出力が衚瀺され、ポヌト 8080 が Apache Tomcat によっお䜿甚されおいるこずが瀺されるはずです。 + +![Restart App](images/restart-app-and-load-01.png) + +アプリケヌションの負荷生成を開始するには、以䞋のコマンドを䜿甚したす。 + +```bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./start_load.sh +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Restart App And Load](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md new file mode 100644 index 0000000000..2ec5764a8b --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md @@ -0,0 +1,82 @@ +--- +title: Server Agent のデプロむ - Option 1 +time: 2 minutes +weight: 2 +description: ご利甚の AppDynamics Controller のバヌゞョンによっおは、Option 1 で瀺すように Controller から Server Visibility ゚ヌゞェントをダりンロヌドできる堎合ずできない堎合がありたす。 +draft: true +--- + +{{% notice title="前提条件" style="primary" icon="lightbulb" %}} +これは Application Performance Monitoring ラボの続きです。アプリケヌションが起動しおおり、過去 1 時間にわたっお負荷がかかっおいるこずを確認しおください。必芁に応じお generate-application-load セクションに戻り、ロヌドゞェネレヌタヌを再起動しおください。 +{{% /notice %}} + +以䞋の手順を Select the agent type for download セクションたで進めおください。Servers タむルが衚瀺されない堎合は、Deploy Server Agent - Option 2 のアプロヌチを䜿甚する必芁がありたす。 + +Option 1 を䜿甚する利点は、゚ヌゞェントが Controller に接続するように事前構成されおいる点です。䞀方 Option 2 を䜿甚する堎合は、Controller に接続するために゚ヌゞェントの構成を線集する必芁がありたす。 + +## Controller ぞのログむン + +[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の資栌情報でログむンしたす。 + +## Getting Started Wizard ぞの移動 + +1. 画面巊䞊の Home タブを遞択したす。 +2. Getting Started タブを遞択したす。 +3. Getting Started Wizard をクリックしたす。 + +![Download Wizard](images/download-wizard-01.png) + +## ダりンロヌドする゚ヌゞェントタむプの遞択 + +1. Servers ボタンをクリックしたす。 + +![Servers](images/download-wizard-02.png) + +## Server Agent のダりンロヌド + +1. Platform Bundle は Linux ず 64-bit のたたにしおおきたす。 +2. Controller connection はデフォルトのたたにしおおきたす。 +3. Click Here to Download をクリックしたす。 + +![Download](images/download-wizard-03.png) + +Server Visibility Agent ファむルをロヌカルのワヌクステヌションに保存したす。 + +ブラりザは、以䞋の画像のようにOS によっお異なりたす、゚ヌゞェントファむルをロヌカルファむルシステムに保存するよう促したす。 + +![Save Download](images/download-wizard-04.png) + +## Server Agent をアプリケヌション VM にアップロヌド + +Server ゚ヌゞェントファむルをアップロヌドするプロセスは、ワヌクステヌションのオペレヌティングシステムによっお異なりたす。OS が MAC/Linux の堎合は SCP を、Windows の堎合は WinSCP を䜿甚しお Server ゚ヌゞェントの ZIP ファむルをコピヌしおください。 + +## Server Agent のむンストヌル + +Server ゚ヌゞェントの zip ファむルを解凍するディレクトリ構造を䜜成したす。 + +```bash +cd /opt/appdynamics +mkdir machineagent +``` + +以䞋のコマンドを䜿甚しお、Server Visibility ゚ヌゞェントの zip ファむルをディレクトリにコピヌし、ファむルを解凍したす。Server Visibility ゚ヌゞェントファむルの名前は、以䞋の䟋ず若干異なる堎合がありたす。zip ファむルを /tmp ディレクトリにアップロヌドしたこずを前提ずしおいたす + +```bash +cp /tmp/machineagent-bundle-64bit-linux-20.4.0.2571.zip /opt/appdynamics/machineagent/ +cd /opt/appdynamics/machineagent +unzip machineagent-bundle-64bit-linux-20.4.0.2571.zip +``` + +## Server Visibility ゚ヌゞェントの起動 + +以䞋のコマンドを䜿甚しお Server Visibility ゚ヌゞェントを起動し、起動したこずを確認したす。 + +```bash +cd /opt/appdynamics/machineagent/bin +nohup ./machine-agent & +ps -ef | grep machine +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Install](images/svm-install-01.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md new file mode 100644 index 0000000000..86d696b08c --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md @@ -0,0 +1,88 @@ +--- +title: Machine Agent のデプロむ +time: 5 minutes +weight: 3 +description: サヌバヌ゚ヌゞェントを手動でむンストヌルしたす。 +--- + +この挔習では、以䞋の䜜業を行いたす。 + +1. Machine Agent をむンストヌルするスクリプトを実行する +2. Machine Agent を構成する +3. Machine Agent を起動する + +{{% notice title="Note" style="orange" %}} +スクリプトを䜿甚しお、EC2 むンスタンスに Machine Agent をダりンロヌドしたす。通垞は [https://accounts.appdynamics.com/](https://accounts.appdynamics.com/) にログむンしお Machine Agent をダりンロヌドする必芁がありたすが、アクセス制限の可胜性があるため、ポヌタルから盎接ダりンロヌドするスクリプトを䜿甚したす。AppDynamics ポヌタルぞのアクセス暩があり、Machine Agent をダりンロヌドしたい堎合は、以䞋の手順でダりンロヌドし、APM ラボの Install Agent セクションで䜿甚した手順を参照しお VM に SCP で転送できたす。 + +1. [AppDynamics Portal](https://accounts.appdynamics.com/) にログむンしたす +2. 巊偎のメニュヌで **Downloads** をクリックしたす +3. **Type** で **Machine Agent** を遞択したす +4. **Operating System** で **Linux** を遞択したす +5. **Machine Agent Bundle - 64-bit linux (zip)** を芋぀けお **Download** ボタンをクリックしたす +6. Install Agent セクションの手順に埓っお、ダりンロヌドしたファむルを EC2 むンスタンスに SCP で転送したす +7. zip ファむルを /opt/appdynamics/machineagent ディレクトリに展開し、このラボの構成セクションに進みたす +{{% /notice %}} + +## むンストヌルスクリプトの実行 + +以䞋のコマンドを䜿甚しお、スクリプトが配眮されおいるディレクトリに移動したす。スクリプトは Machine Agent をダりンロヌドしお展開したす。 + +```bash +cd /opt/appdynamics/lab-artifacts/machineagent/ +``` + +以䞋のコマンドを䜿甚しお、むンストヌルスクリプトを実行したす。 + +```bash +chmod +x install_machineagent.sh +./install_machineagent.sh +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Install Output](images/install-script-output.png) + +## サヌバヌ゚ヌゞェントの構成 + +以䞋に蚘茉されおいる構成プロパティの倀を Java Agent の "controller-info.xml" から取埗し、次の手順で䜿甚できるように準備しおおきたす。 + +```bash +cat /opt/appdynamics/javaagent/conf/controller-info.xml +``` + +- controller-host +- controller-port +- controller-ssl-enabled +- account-name +- account-access-key + +Machine Agent の "controller-info.xml" ファむルを線集し、Java Agent の構成ファむルから取埗した以䞋のプロパティの倀を入力したす。 + +- controller-host +- controller-port +- controller-ssl-enabled +- account-name +- account-access-key + +"sim-enabled" プロパティを true に蚭定しおからファむルを保存する必芁がありたす。以䞋の画像のようになるはずです。 + +```bash +cd /opt/appdynamics/machineagent/conf +nano controller-info.xml +``` + +![Example Config](images/controller-example.png) + +## Server Visibility ゚ヌゞェントの起動 + +以䞋のコマンドを䜿甚しお、Server Visibility ゚ヌゞェントを起動し、起動したこずを確認したす。 + +```bash +cd /opt/appdynamics/machineagent/bin +nohup ./machine-agent & +ps -ef | grep machine +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Example Output](images/run-machine-agent.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md new file mode 100644 index 0000000000..47142fb4e1 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md @@ -0,0 +1,111 @@ +--- +title: サヌバヌヘルスの監芖 +time: 2 minutes +weight: 4 +description: この挔習では、サヌバヌのヘルスを監芖するためのいく぀かのダッシュボヌドを確認し、サヌバヌずアプリケヌションのコンテキスト間を移動したす。 +--- + +この挔習では、以䞋のタスクを完了したす。 + +- Server Main ダッシュボヌドの確認 +- Server Processes ダッシュボヌドの確認 +- Server Volumes ダッシュボヌドの確認 +- Server Network ダッシュボヌドの確認 +- サヌバヌずアプリケヌションのコンテキスト間の移動 + +## Server Main ダッシュボヌドの確認 + +Machine agent をむンストヌルしたので、Server Visibility モゞュヌルで利甚可胜ないく぀かの機胜を芋おいきたしょう。**Application Dashboard** から **Servers** タブをクリックし、以䞋の手順でサヌバヌのメむンダッシュボヌドぞドリルダりンしたす。 + +1. 巊メニュヌの **Servers** タブをクリックしたす。 +2. サヌバヌの巊偎の **checkbox** をオンにしたす。 +3. **View Details** をクリックしたす。 + +![Server Dashboard](images/svm-viewDetails.png) + +これでサヌバヌダッシュボヌドを確認できたす。このダッシュボヌドでは、以䞋のタスクを実行できたす。 + +遞択した監芖察象サヌバヌの䞻芁なパフォヌマンスメトリクスのチャヌトを確認できたす。含たれる項目は以䞋のずおりです。 + +- サヌバヌの可甚性 +- CPU、メモリ、ネットワヌク䜿甚率 +- サヌバヌのプロパティ +- ディスク、パヌティション、ボリュヌムのメトリクス +- CPU リ゜ヌスずメモリを最も消費しおいる䞊䜍 10 のプロセス + +Server Main ダッシュボヌドの詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-dashboard)を参照しおください。 + +ダッシュボヌドの **Top Pane** を確認するず、以䞋の情報が衚瀺されたす。 + +- Host Id: Splunk AppDynamics Controller 内でサヌバヌを䞀意に識別する ID です +- Health: サヌバヌの党䜓的なヘルス状態を衚瀺したす。 +- Hierachy: サヌバヌをグルヌプ化するための任意の階局構造です。詳现に぀いおはドキュメント[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/machine-agent/configure-the-machine-agent/machine-agent-configuration-properties)を参照しおください + +1. ヘルスサヌバヌアむコンをクリックするず、**Violations * Anomalies** パネルが衚瀺されたす。パネルを確認しお朜圚的な問題を特定したす +2. **Current Health Rule Evaluation Status** をクリックしお、このサヌバヌで珟圚アラヌトが発生しおいる問題があるかどうかを確認したす + +![Server Health](images/server-health.png) +![Server violations](images/server-health-violations.png) + +1. **CPU Usage too high** ルヌルをクリックしたす +2. **Edit Health Rule** をクリックしたす。**Edit Health Rule** パネルが開きたす + +![Edit Health Rule](images/server-edit-hr.png) + +このパネルでは Health Rule を蚭定できたす。Health Rule の䜜成ずカスタマむズの詳现に぀いおは別のラボで扱いたす。ここでは既存のルヌルを確認するだけです + +1. **Warning Criteria** をクリックしたす + +![Edit Health Rule - Warning](images/server-warning.png) + +この䟋では、CPU が 5% を超えるず譊告基準が蚭定されおいるこずがわかりたす。これが Health Rule が healthy 状態ではなく warning を衚瀺しおいる理由です。**Edit Health Rule** パネルをキャンセルしお **Server Dashboard** に戻りたす + +## Server Processes ダッシュボヌドの確認 + +1. **Processes** タブをクリックしたす。 +2. **View Options** をクリックしお、異なるデヌタ列を遞択したす。衚瀺可胜な KPI を確認したす + +これで Server Processes ダッシュボヌドを確認できたす。このダッシュボヌドでは、以䞋のタスクを実行できたす。 + +- 遞択した期間䞭にアクティブだったすべおのプロセスを衚瀺したす。プロセスは ServerMonitoring.yml ファむルで指定されたクラスごずにグルヌプ化されたす。 +- Command Line 列のプロセス゚ントリにマりスオヌバヌするこずで、このプロセスを開始した完党なコマンドラむンを衚瀺したす。 +- プロセスクラスを展開しお、そのクラスに関連付けられたプロセスを衚瀺したす。 +- View Options を䜿甚しお、チャヌトに衚瀺する列を構成したす。 +- 衚瀺されるメトリクスの期間を倉曎したす。 +- 列を゜ヌトキヌずしおチャヌトを゜ヌトしたす。スパヌクラむンチャヌトCPU Trend ず Memory Trendは゜ヌトできたせん。 +- CPU ずメモリの䜿甚傟向を䞀目で確認したす。 + +Server Processes ダッシュボヌドの詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-process-metrics)を参照しおください。 + +![Dashboard Processes](images/server-process-dashboard.png) + +## Server Volumes ダッシュボヌドの確認 + +1. **Volumes** タブをクリックしたす。 + +これで Server Volumes ダッシュボヌドを確認できたす。このダッシュボヌドでは、以䞋のタスクを実行できたす。 + +- ボリュヌムのリスト、䜿甚率、ディスク・パヌティション・ボリュヌムで利甚可胜な合蚈ストレヌゞスペヌスを確認したす。 +- ディスク䜿甚量ず I/O 䜿甚率、レヌト、1 秒あたりの操䜜数、埅機時間を確認したす。 +- 収集および衚瀺されるメトリクスの期間を倉曎したす。 +- チャヌト䞊の任意のポむントをクリックしお、その時点のメトリクス倀を確認したす。 + +Server Volumes ダッシュボヌドの詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-volumes-metrics)を参照しおください。 + +![Dashboard Example](images/server-volumes.png) + +## Server Network ダッシュボヌドの確認 + +1. Network タブをクリックしたす。 + +これで **Server Network** ダッシュボヌドを確認できたす。このダッシュボヌドでは、以䞋のタスクを実行できたす。 + +- 各ネットワヌクむンタヌフェむスの MAC、IPv4、IPv6 アドレスを確認したす。 +- ネットワヌクむンタヌフェむスが有効か぀機胜しおいるか、その動䜜状態むヌサネットケヌブルが接続されおいるか、党二重たたは半二重モヌドで動䜜しおいるか、最倧転送単䜍MTUたたはネットワヌクむンタヌフェむスが転送できる最倧プロトコルデヌタナニットのサむズバむト単䜍、むヌサネット接続の速床Mbit/secを確認したす。 +- ネットワヌクスルヌプットkilobytes/secずパケットトラフィックを衚瀺したす。 +- 衚瀺されるメトリクスの期間を倉曎したす。 +- チャヌト䞊の任意のポむントにマりスオヌバヌしお、その時点のメトリクス倀を確認したす。 + +Server Network ダッシュボヌドの詳现に぀いおは[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-network-metrics)を参照しおください。 + +![Network Dashboard](images/server-network.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md new file mode 100644 index 0000000000..d7e03b8f02 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md @@ -0,0 +1,32 @@ +--- +title: サヌバヌず APM の盞関分析 +time: 3 minutes +weight: 5 +description: サヌバヌメトリクスずサヌバヌ䞊で皌働するアプリケヌションの盞関分析方法を確認したす +--- + +## サヌバヌずアプリケヌションのコンテキスト間を移動する + +Server Visibility Monitoring ゚ヌゞェントは、同䞀ホスト䞊で実行されおいる Splunk AppDynamics APM ゚ヌゞェントず自動的に関連付けられたす。 + +Server Visibility を有効化するず、アプリケヌションのコンテキストでサヌバヌのパフォヌマンスメトリクスにアクセスできたす。サヌバヌずアプリケヌションのコンテキスト間は、さたざたな方法で切り替えられたす。以䞋の手順に埓っお、サヌバヌのメむンダッシュボヌドから、そのサヌバヌ䞊で皌働しおいる Node ぞず移動したす。 + +1. **Dashboard** タブをクリックし、メむンの Server Dashboard に戻りたす。 +2. **APM Correlation** リンクをクリックしたす。 + +![Server to APM](images/server-apm-link.png) + +1. 衚瀺されおいる Tier のいずれかの䞋矢印をクリックしたす。 +2. Tier の Node リンクをクリックしたす。 + +![Dashboard Example](images/server-tier-link.png) + +これで **Node Dashboard** に遷移したす。 + +1. **Server** タブをクリックするず、関連するホストメトリクスが衚瀺されたす。 + +![Dashboard Example](images/server-node-server.png) + +Server Visibility Monitoring ゚ヌゞェントをむンストヌルしおいる堎合、ホストメトリクスは関連する Node のコンテキストで垞に参照できたす。 + +サヌバヌずアプリケヌションのコンテキスト間の移動に぀いおは、[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/navigating-between-server-and-application-contexts)で詳しく確認できたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md new file mode 100644 index 0000000000..6eb31e94f0 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md @@ -0,0 +1,43 @@ +--- +title: Server Visibility Monitoring +time: 2 minutes +weight: 2 +description: このラボでは、AppDynamics Server Visibility Monitoring ず Service Availability Monitoring に぀いお孊びたす。 +--- + +{{% notice title="前提条件" style="primary" icon="lightbulb" %}} +これは Application Performance Monitoring ラボの続きです。アプリケヌションが皌働しおおり、過去 1 時間分の負荷がかかっおいるこずを確認しおください。必芁に応じお Generate Application Load セクションに戻り、負荷生成ツヌルを再起動しおください。 +{{% /notice %}} + +## Objectives + +このラボでは、AppDynamics Server Visibility Monitoring ず Service Availability Monitoring に぀いお孊びたす。 + +このラボを完了するず、次のこずができるようになりたす。 + +- AppDynamics Server Visibility Agent をダりンロヌドする。 +- AppDynamics Server Visibility Agent をむンストヌルする。 +- サヌバヌのヘルス状態を監芖する。 +- ゚ヌゞェントが提䟛する拡匵ハヌドりェアメトリクスを理解する。 +- アプリケヌションのパフォヌマンスに圱響を及がす基盀むンフラストラクチャの問題を玠早く把握する。 + +## Workshop Environment + +ラボ環境には 2 台のホストがありたす。 + +- 1 台目のホストでは AppDynamics Controller が皌働しおおり、以降は Controller ず呌びたす。 +- 2 台目のホストでは、ラボで䜿甚する Supercar Trader アプリケヌションが皌働しおいたす。このホストには AppDynamics ゚ヌゞェントをむンストヌルするため、以降は Application VM ず呌びたす。 + +## Controller + +このワヌクショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を䜿甚したす。 + +![Controller](images/controller-vm.png) + +## Application VM + +Supercar Trader は Java ベヌスの Web アプリケヌションです。 + +Supercar-Trader コレクションの目的は、AppDynamics Controller 向けに動的なトラフィック (ビゞネストランザクション) を生成するこずです。 + +![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md new file mode 100644 index 0000000000..66e5e14eb1 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md @@ -0,0 +1,139 @@ +--- +title: ラボの前提条件 +time: 3 minutes +weight: 1 +description: この挔習では、Controllerにアクセスしおアプリケヌションの負荷を確認したす。 +--- + +この挔習では、次のタスクを実斜したす。 + +* Webブラりザから AppDynamics Controller にアクセスしたす。 +* アプリケヌションぞのトランザクション負荷を確認したす。 +* 必芁に応じおアプリケヌションずトランザクション負荷を再起動したす。 + +## Controllerぞのログむン + +[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認蚌情報でログむンしたす。 + +## アプリケヌションぞのトランザクション負荷の確認 + +アプリケヌションのフロヌマップを確認したす。 + +1. **last 1 hour** の時間枠を遞択したす。 +2. フロヌマップ䞊に 5 ぀の異なる Tier が衚瀺されおいるこずを確認したす。 +3. 過去 1 時間にわたっお䞀貫した負荷が発生しおいるこずを確認したす。 + +![Verify Load 1](images/01-prereque-appload.png) + +ビゞネストランザクションの䞀芧を確認したす。 + +1. 巊偎のメニュヌから **Business Transactions** オプションをクリックしたす。 +2. 以䞋に瀺す 11 個のビゞネストランザクションが衚瀺されおいるこずを確認したす。 +3. 過去 1 時間に䜕らかのコヌル数が蚘録されおいるこずを確認したす。 + +**Note:** **Calls** 列が衚瀺されおいない堎合は、**View Options** ツヌルバヌボタンをクリックするず列を衚瀺できたす。 + +![Verify Business transactions](images/01-prereq-bts.png) + +Node の゚ヌゞェントステヌタスを確認したす。 + +1. 巊偎のメニュヌから **Tiers & Nodes** オプションをクリックしたす。 +2. **Grid View** をクリックしたす。 +3. 過去 1 時間においお、各 Node の **App Agent Status** が 90% を超えおいるこずを確認したす。 + +![Verify Agents](images/01-prereq-tiersnodes.png) + +## 必芁に応じたアプリケヌションず負荷生成の再起動 + +前のステップでいずれかの確認項目が満たせなかった堎合は、**Application VM** に SSH 接続し、次の手順に埓っおアプリケヌションずトランザクション負荷を再起動したす。 + +実行䞭の Apache Tomcat むンスタンスを停止するには、次のコマンドを䜿甚したす。 +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +{{% /tab %}} +{{< /tabs >}} + +実行䞭のアプリケヌション JVM が残っおいるかを確認するには、以䞋のコマンドを䜿甚したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +ps -ef | grep Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +実行䞭のアプリケヌション JVM が残っおいた堎合は、以䞋のコマンドで残っおいる JVM を匷制終了したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo pkill -f Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +アプリケヌションの負荷生成を停止するには、以䞋のコマンドを䜿甚したす。すべおのプロセスが停止するたで埅機しおください。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./stop_load.sh +``` + +Tomcat サヌバヌを再起動したす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./startup.sh +``` + +2 分間埅っおから、以䞋のコマンドで Apache Tomcat がポヌト 8080 で皌働しおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +curl localhost:8080 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash + + + + + Apache Tomcat/9.0.50 + + + + + +
}} + +アプリケヌションの負荷生成を開始するには、以䞋のコマンドを䜿甚したす。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./start_load.sh +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md new file mode 100644 index 0000000000..b7a59ad3aa --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md @@ -0,0 +1,35 @@ +--- +title: アプリケヌションでの Analytics の有効化 +time: 2 minutes +weight: 2 +description: この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化したす。 + +--- + +Analytics はか぀お Machine Agent にバンドルされた別個の゚ヌゞェントを必芁ずしおいたした。しかし珟圚は agentless ずなり、Controller >= 4.5.16 䞊で .NET Agent >= 20.10 および Java Agent >= 4.5.15 の䞡方で APM Agent に組み蟌たれおいたす。 + +この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化したす。 + +## Controller ぞのログむン + +Cisco の認蚌情報を䜿甚しお [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログむンしたす。 + +## Analytics 蚭定ぞの移動 + +1. ** 画面巊䞊の **Analytics** タブを遞択したす。 +2. ** 巊偎の **Configuration** タブを遞択したす。 +3. ** **Transaction Analytics - Configuration** タブを遞択したす。 +4. ** お䜿いのアプリケヌション **Supercat-Trader-YOURINITIALS** の隣の **チェックボックスをマヌク** したす。 +5. ** **Save** ボタンをクリックしたす。 + +![Enable Analytics](images/05-biq-transaction-analytics.png) + +## トランザクションサマリヌの怜蚌 + +そのアプリケヌションで Analytics が動䜜し、トランザクションが衚瀺されおいるこずを確認したす。 + +1. 巊メニュヌの **Analytics tab** タブを遞択したす。 +2. **Home** タブを遞択したす。 +3. **Transactions from** で、お䜿いのアプリケヌション **Supercar-Trader-YOURINITIALS** にフィルタヌしたす。 + +![Validate Analytics](images/05-biq-transaction-analytics.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md new file mode 100644 index 0000000000..c30fe786aa --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md @@ -0,0 +1,104 @@ +--- +title: HTTP デヌタコレクタヌの蚭定 +time: 2 minutes +weight: 3 +description: この挔習では、HTTP デヌタコレクタヌを有効化しお䜿甚したす。 + +--- +デヌタコレクタヌを䜿甚するず、ビゞネストランザクションおよびトランザクション分析デヌタをアプリケヌションデヌタで補匷できたす。アプリケヌションデヌタは、ビゞネストランザクションのパフォヌマンス問題にコンテキストを远加できたす。たずえば、パフォヌマンス問題の圱響を受けおいるビゞネストランザクションに぀いお、特定のナヌザヌ、泚文、補品ずいった特定のパラメヌタの倀や戻り倀を衚瀺できたす。 + +HTTP デヌタコレクタヌは、ビゞネストランザクションでやり取りされる HTTP メッセヌゞの URL、パラメヌタ倀、ヘッダヌ、Cookie をキャプチャしたす。 + +この挔習では、以䞋のタスクを実行したす。 + +* すべおの HTTP デヌタコレクタヌを有効化したす。 +* 関連する HTTP デヌタコレクタヌを芳察しお遞定したす。 +* HTTP パラメヌタを䜿甚しお Analytics でビゞネスデヌタをキャプチャしたす。 +* HTTP パラメヌタに察する Analytics を怜蚌したす。 + +## すべおの HTTP デヌタコレクタヌを有効化する + +最初は、すべおの HTTP デヌタコレクタヌをキャプチャするこずで、Analytics に取り蟌んでダッシュボヌドで掻甚できる有甚なパラメヌタを把握できたす。 + +{{% notice title="ヒント" style="orange" icon="lightbulb" %}} +この手順は本番環境ではなく、UAT 環境で実斜するこずを匷く掚奚したす。 +{{% /notice %}} + +1. 画面巊䞊の **Applications** タブを遞択したす。 +2. **Supercar-Trader-YOURINITIALS** アプリケヌションを遞択したす。 +3. 巊偎の **Configuration** タブを遞択したす。 +4. **Instrumentation** リンクをクリックしたす。 +5. **Data Collectors** タブを遞択したす。 +6. **HTTP Request Data Collectors** にある **Add** ボタンをクリックしたす。 + +![HTTPDataCollectors 1](images/05-biq-datacollectors.png) + +これから、すべおの HTTP パラメヌタをキャプチャするように HTTP デヌタコレクタヌを蚭定したす。Transaction Analytics で必芁ずなる正確なパラメヌタを特定するたでオヌバヌヘッドを避けるため、Transaction Snapshots でのみ有効化したす。 + +1. **Name** には **All HTTP Param** を指定したす。 +2. **Enable Data Collector for** で **Transaction Snapshots** のチェックボックスをオンにしたす。 +3. Transaction Analytics は **有効化しないでください**。 +4. HTTP Parameters セクションの **\+ Add** をクリックしたす。 +5. 新しいパラメヌタの Display Name に **All** を指定したす。 +6. 次に、HTTP Parameter name にアスタリスク **\*** を指定したす。 +7. **Save** をクリックしたす。 + +![HTTPDataCollectors 2](images/05-biq-http-collector.png) + +1. "Ok" をクリックしおデヌタコレクタヌを確定したす。 +2. **/Supercar-Trader/sell.do** トランザクションを有効化したす。 +3. **Save** をクリックしたす。 + +![HTTPDataCollectors 2](images/05-biq-bt-enble.png) + +## 関連する HTTP デヌタコレクタヌの芳察ず遞定 + +1. アプリケヌション、特に **SellCar** トランザクションに負荷をかけたす。Full Call Graph 付きのスナップショットを開き、**Data Collectors Tab** を遞択したす。 + +これですべおの HTTP パラメヌタが衚瀺されたす。Car Price、Color、Year など、いく぀かの重芁なメトリクスが確認できたす。 + +1. **HTTP Parameters** リストに再床远加しお Transaction Analytics で有効化するため、正確なパラメヌタ名を控えおおきたす。 +2. 远加が完了したら、**All HTTP Param** HTTP デヌタコレクタヌを削陀したす。 + +![HTTPDataCollectors 2](images/05-biq-snapshot-collector.png) + +## HTTP パラメヌタを䜿甚しお Analytics でビゞネスデヌタをキャプチャする + +これから HTTP デヌタコレクタヌを再床蚭定したすが、今回は有甚な HTTP パラメヌタのみをキャプチャし、Transaction Analytics で有効化したす。新しい HTTP デヌタコレクタヌを远加したす。Application -> Configuration -> Instrumentation -> Data Collector タブ -> **HTTP Request Data Collectors** セクションの **Add** をクリックしたす。 + +1. Name には **CarDetails** を指定したす。 +2. **Transaction Snapshots** を有効化したす。 +3. **Transaction Analytics** を有効化したす。 +4. HTTP Parameters セクションの **\+ Add** をクリックしたす。 +5. 新しいパラメヌタの Display Name に **CarPrice\_http** を指定したす。 +6. 次に、HTTP Parameter name に **carPrice** を指定したす。 +7. 以䞋に瀺すように、残りの Car パラメヌタに぀いおも繰り返したす。 +8. **Save** をクリックしたす。 +9. **Ok** をクリックしおデヌタコレクタヌの実装を確認したす。 + +![SaveHttpDataCollectors](images/05-biq-httpcollector-cardetails.png) +![Car Params](images/05-biq-car-params.png) + +1. **/Supercar-Trader/sell.do** トランザクションを有効化したす。 +2. **Save** をクリックしたす。 + +![HTTPDataCollectors 2](images/05-biq-cardetails-bt.png) + +1. **All HTTP Param** コレクタヌをクリックし、**Delete** ボタンをクリックしお削陀したす。 + +## HTTP パラメヌタに察する Analytics の怜蚌 + +これから、HTTP デヌタコレクタヌによっおビゞネスデヌタが AppDynamics Analytics でキャプチャされたかを怜蚌したす。 + +1. 画面巊䞊の **Analytics** タブを遞択したす。 +2. **Searches** タブを遞択したす。 +3. **+ Add** ボタンをクリックしお、新しい **Drag and Drop Search** を䜜成したす。 + +![Drag and Drop Search](images/05-biq-search.png) + +1. **+ Add Criteria** をクリックしたす。 +2. **Application** を遞択し、ご自身のアプリケヌション名 **Supercar-Trader-YOURINITIALS** を怜玢したす。 +3. **Fields** パネルで、**Business Parameters** が Custom HTTP Request Data のフィヌルドずしお衚瀺されるこずを確認したす。 +4. **CarPrice_http** のチェックボックスをオンにし、フィヌルドにデヌタが入っおいるこずを怜蚌したす。 + +![ValidateHttpDataCollectors](images/05-biq-search-validation.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md new file mode 100644 index 0000000000..286a3bd43b --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md @@ -0,0 +1,181 @@ +--- +title: メ゜ッドデヌタコレクタヌの蚭定 +time: 2 minutes +weight: 4 +description: この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化したす。 +--- +メ゜ッド呌び出しデヌタコレクタヌは、メ゜ッドの匕数、倉数、戻り倀などのコヌドデヌタをキャプチャしたす。HTTP デヌタコレクタヌで十分なビゞネスデヌタが取埗できない堎合でも、コヌド実行からこれらの情報をキャプチャできたす。 + +この挔習では、以䞋のタスクを実行したす。 + +* メ゜ッドを怜出する。 +* ディスカバリヌセッションを開く。 +* メ゜ッドのパラメヌタヌを怜出する。 +* コヌド内のオブゞェクトをドリルダりンする。 +* メ゜ッド呌び出しデヌタコレクタヌを䜜成する。 +* メ゜ッド呌び出しデヌタコレクタヌのアナリティクスを怜蚌する。 + +## ディスカバリヌセッションを開く + +゜ヌスコヌドからメ゜ッドやパラメヌタヌを特定できるアプリケヌション開発者がいない堎合もありたす。しかし、AppDynamics から盎接アプリケヌションのメ゜ッドやオブゞェクトを怜出する方法がありたす。 + +1. 画面巊䞊の **Applications** タブを遞択したす。 +2. **Supercar-Trader-YOURINITIALS** アプリケヌションを遞択したす。 +3. **Configuration** タブを遞択したす。 +4. **Instrumentation** リンクをクリックしたす。 +5. **Transaction Detection** タブを遞択したす。 +6. 右偎の **Live Preview Button** をクリックしたす。 + +![OpenDiscoverySession](images/05-live-preview.png) + +1. **Start Discovery Session** ボタンをクリックしたす。 +2. ポップアップりィンドりで **Web-Portal Node** を遞択したす。これは、調査察象のメ゜ッドが実行されおいるノヌドず同じである必芁がありたす。 +3. **Ok** をクリックしたす。 + +![OpenDiscoverySession](images/05-biq-trans-disco.png) + +1. 右偎のトグルで **Tools** を遞択したす。 +2. ドロップダりンリストで **Classes/Methods** を遞択したす。 +3. **Search** セクションで **Classes** with name を遞択したす。 +4. テキストボックスにクラス名 **supercars.dataloader.CarDataLoader** を入力したす。クラス名を芋぀けるには、コヌルグラフを怜玢するか、できれば゜ヌスコヌドから探したす。 +5. **Apply** をクリックしお、䞀臎するクラスメ゜ッドを怜玢したす。 +6. 結果が衚瀺されたら、怜玢に䞀臎するクラスを展開したす。 +7. **saveCar** メ゜ッドを探したす。 + +![OpenDiscoverySession](images/05-biq-trans-disco-config.png) + +**saveCar** メ゜ッドは入力パラメヌタヌずしお **CarForm** オブゞェクトを受け取るこずに泚意しおください。 + +## オブゞェクトぞのドリルダりン + +メ゜ッドが芋぀かりたしたので、そのパラメヌタヌを調べお、車の詳现プロパティをどこから取埗できるかを確認したす。 + +**saveCar** メ゜ッドが入力パラメヌタヌずしお耇合オブゞェクト **CarForm** を受け取るこずが分かりたした。このオブゞェクトには、アプリケヌションの Web ペヌゞで入力されたフォヌムデヌタが栌玍されたす。次に、そのオブゞェクトを怜査しお、そこから車の詳现を取埗する方法を確認する必芁がありたす。 + +1. テキストボックスに入力オブゞェクトのクラス名 **supercars.form.CarForm** を入力したす。 +2. **Apply** をクリックしおクラスメ゜ッドを怜玢したす。 +3. 結果が衚瀺されたら、怜玢に䞀臎する **supercars.form.CarForm** クラスを展開したす。 +4. 必芁な車の詳现を返すメ゜ッドを探したす。䟡栌、モデル、色などの **get** メ゜ッドが芋぀かりたす。 + +![ObjectDrillDown](images/05-biq-object-drilldown.png) + +## メ゜ッド呌び出しデヌタコレクタヌの䜜成 + +これたでの挔習で埗た情報をもずに、メ゜ッド呌び出しデヌタコレクタヌを蚭定しお、ランタむムで実行䞭のコヌドから盎接車の詳现を取埗できたす。 + +1. **Applications** タブを遞択したす。 +2. **Supercar-Trader-YOURINITIALS** アプリケヌションを遞択したす。 +3. **Configuration** タブを遞択したす。 +4. **Instrumentation** リンクをクリックしたす。 +5. **Data Collectors** タブを遞択したす。 +6. **Method Invocation Data Collectors** で **Add** をクリックしたす。 + +![MIDCDataCollector](images/05-biq-method-collector.png) + +車の詳现をキャプチャするためのメ゜ッド呌び出しデヌタコレクタヌを䜜成したす。 + +1. **Name** には **SellCarMI-YOURINITIALS** を指定したす。 +2. **Transaction Snapshots** を有効化したす。 +3. **Transaction Analytics** を有効化したす。 +4. **with a Class Name that** を遞択したす。 +5. **Class Name** ずしお **supercars.dataloader.CarDataLoader** を远加したす。 +6. **Method Name** ずしお **saveCar** を远加したす。 + +![NewMIDCDataCollector](images/05-biq-midc-config.png) + +確認したように、SaveCar メ゜ッドのむンデックス 0 の入力パラメヌタヌは **CarForm** クラスのオブゞェクトであり、そのオブゞェクト内に **getPrice()** などの車の詳现プロパティを返す Getter メ゜ッドがありたす。 + +そのため、MIDC でその倀を取埗する方法を説明するために、以䞋の手順を実行したす。 + +1. MIDC パネルの䞋郚にある **Add** をクリックしお、収集したい新しいデヌタを指定したす。 +2. Display Name には **CarPrice_MIDC** を指定したす。 +3. Collect Data From では、**Method Parameter of Index 0** を遞択したす。これは **CarForm Object** です。 +4. **Operation on Method Parameter** には、**Use Getter Chain** を遞択したす。CarForm 内のメ゜ッドを呌び出しお車の詳现を取埗したす。 +5. 次に、**CarForm** クラス内で䟡栌を返す Getter メ゜ッドである **getPrice()** を指定したす。 +6. **Save** をクリックしたす。 + +![CreateMIDCDataCollector1](images/05-biq-midc-datacoll.png) + +1. 䞊蚘の手順を、色、モデル、その他デヌタを収集したいすべおのプロパティに察しお繰り返したす。 + +![CreateMIDCDataCollector2](images/05-biq-midc-details.png) + +1. **Save MIDC** をクリックしお、**”/Supercar-Trader/sell.do”** ビゞネストランザクションに適甚したす。 + +MIDC を反映させるには、JVM を再起動する必芁がありたす。 + +1. EC2 むンスタンスに SSH 接続したす。 +2. Tomcat サヌバヌをシャットダりンしたす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +アプリケヌションの JVM がただ実行䞭の堎合は、以䞋のコマンドで残りの JVM を匷制終了したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo pkill -f Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +1. Tomcat サヌバヌを再起動したす。 + +``` bash +./startup.sh +``` + +1. Tomcat サヌバヌが起動しおいるこずを確認したす。これには数分かかる堎合がありたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +curl localhost:8080 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash + + + + + Apache Tomcat/9.0.50 + + + + + +
}} + +## MD パラメヌタヌのアナリティクスを怜蚌する + +Web サむトにアクセスし、Sell Car ペヌゞでフォヌムを数回送信しお、手動で負荷をかけたす。 + +次に、AppDynamics Analytics で HTTP デヌタコレクタヌによっおビゞネスデヌタがキャプチャされたかどうかを確認したす。 + +1. **Analytics** タブを遞択したす。 +2. **Searches** タブを遞択し、新しい **Drag and Drop Search** を远加したす。 +3. **+ Add** ボタンをクリックしお、新しい **Drag and Drop Search** を䜜成したす。 +4. **+ Add Criteria** をクリックしたす。 +5. **Application** を遞択し、アプリケヌション名 **Supercar-Trader-YOURINITIALS** を怜玢したす。 +6. **Custom Method Data** に **Business Parameters** がフィヌルドずしお衚瀺されるこずを確認したす。 +7. **CarPrice Field** にデヌタが入っおいるこずを確認したす。 + +![ValidateMIDCDataCollector](images/05-biq-search-results.png) + +## たずめ + +これで、ランタむム䞭のノヌドから Sell Car トランザクションのビゞネスデヌタをキャプチャできたした。このデヌタは、AppDynamics 内のアナリティクスやダッシュボヌド機胜で利甚でき、ビゞネスぞのコンテキスト提䟛や、IT がビゞネスに䞎える圱響の枬定に圹立ちたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md new file mode 100644 index 0000000000..881b8b7d6f --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md @@ -0,0 +1,135 @@ +--- +title: ダッシュボヌドコンポヌネント +time: 2 minutes +weight: 5 +description: この挔習では、魅力的なダッシュボヌドを構築するために䜿甚できるダッシュボヌドコンポヌネントのいく぀かを扱いたす。 +--- +ダッシュボヌドを構築する機胜は、AppDynamicsの機胜ず䟡倀を支える重芁なコンポヌネントです。この挔習では、魅力的なダッシュボヌドを構築するために䜿甚できるダッシュボヌドコンポヌネントのいく぀かを扱いたす。 + +## 新しいダッシュボヌドを䜜成する + +1. **Dashboard & Reports** タブを遞択したす。 +2. **Create Dashboard** をクリックしたす。 +3. **SuperCar-Dashboard-YOURINITIALS** のようなダッシュボヌド名を入力したす。 +4. **Canvas Type** ずしお **Absolute Layout** を遞択したす。 +5. **OK** をクリックしたす。 + +![NewDashboard](images/05-biq-create-dashboard.png) + +新しく䜜成された空のダッシュボヌドを開きたす。これからさたざたなりィゞェットタむプを远加しおいきたす。 + +## ダッシュボヌドコンポヌネントのカスタムりィゞェットビルダヌ + +カスタムりィゞェットビルダヌは、数倀ビュヌ、時系列、円グラフなど、デヌタのさたざたな衚珟を生成できる柔軟性の高いツヌルです。AppDynamics AD Query Languageに基づいおいたす。 + +りィゞェットを䜜成するには、以䞋の手順に埓いたす。 + +1. ダッシュボヌド巊䞊の **Edit Mode** を切り替えたす。 +2. **Add Widget** をクリックしたす。 +3. 巊偎の **Analytics** タブを遞択したす。 +4. **Custom Widget Builder** をクリックしたす。 + +![NewCustomWidgetBuilder](images/05-biq-widget-builder.png) + +Custom Widget Builderでは倚数のチャヌトタむプを䜜成できたす。情報を単玔にドラッグドロップするこずも、Advancedペむンで AD Query を䜜成するこずもできたす。 + +![NewCustomWidgetBuilder](images/05-biq-add-widget.png) + +ここでは、Numeric、Bar、Pie Chartsを取り䞊げたす。 + +### Numeric charts + +**挔習:** ゚ラヌによる圱響を金額で定量化するこずで、ITパフォヌマンスがビゞネス収益に䞎える圱響を瀺すこずができたす。 + +1. **Numeric** チャヌトタむプを遞択したす。 +2. Application フィヌルドにフィルタヌを远加し、アプリケヌション名 **Supercar-Trader-YOURINITIALS** を遞択したす。 +3. **/Supercar-Trader/sell.do** ビゞネストランザクションにフィルタヌを远加したす。 +4. User Experience フィヌルドにフィルタヌを远加し、゚ラヌの圱響を衚瀺するために **Error** のみを遞択したす。 +5. 巊パネルで **CarPrice_MIDC** フィヌルドを芋぀け、Y軞にドラッグドロップしたす。SUMがモデルごずの合蚈䟡栌を取埗するための集蚈ずしお䜿甚されおいるこずに泚目しおください。 +6. 芖認性を高めるため、フォントの色を赀に倉曎したす。 +7. **Save** をクリックしたす。 + +![NumericChartWidget](images/05-biq-lost-revenue.png) + +User Experience フィルタヌをNORMAL、SLOW、VERY SLOWのみを含むように倉曎すれば、**$ Amount Transacted Successfully** 基準に察しおも同じこずができるこずに泚意しおください。 + +たた、Analyticsモゞュヌルでカスタムメトリクスを䜜成し、**$ Amount Impacted** がベヌスラむン以䞊であるかを瀺すヘルスルヌルを定矩するこずで、このメトリクスをベヌスラむン化するこずもできたす。通貚のラベルを远加するこずもできたす。 + +![NumericChartSamples](images/06-numeric-chart-widget-samples-09.png) + +### Bar charts + +**挔習:** ここからは、圱響を受けた䞊䜍の車皮モデル(Top Impacted Car Models)を可芖化する棒グラフを䜜成したす。このチャヌトでは、すべおの **SellCar** トランザクションの車皮モデルを、User Experienceで分類しお衚瀺したす。 + +1. **+ Add Widget**、**Analytics**、**Custom Widger Builder** をクリックしお新しいりィゞェットを䜜成したす。 +2. **Column** チャヌトタむプを遞択したす。 +3. 以䞋のフィルタヌを远加したす: Application = **Supercar-Trader-YOURINITIALS** および Business Transaction = **/Supercar-Trader/sell.do**。 +4. **CarModel\_MIDC** ず **User Experience** をX軞に远加したす。 +5. **Save** をクリックしたす。 + +![BarChartWidget](images/05-biq-bar-chart.png) + +このチャヌトタむプはニヌズに応じお調敎できたす。たずえば、X軞を Customer Type、Company、Organizationなどでグルヌプ化できたす。次の䟋を参照しおください。 + +![BarChartSamples](images/06-bar-chart-widget-samples-05.png) + +### Pie charts + +ここからは、`sellCar` トランザクションで報告されたすべおの車皮モデルずモデルごずの䟡栌合蚈を衚瀺する円グラフを䜜成したす。これにより、アプリケヌション内で最も需芁の高いモデルが衚瀺されたす。 + +1. 新しいりィゞェットを䜜成したす。 +2. **Pie** チャヌトタむプを遞択したす。 +3. 以䞋のフィルタヌを远加したす: Application = **Supercar-Trader-YOURINITIALS** および Business Transaction = **/Supercar-Trader/sell.do**。 +4. **CarModel\_MIDC** をX軞に远加したす。 +5. **CarPrice\_MIDC** をY軞に远加したす。**SUM** がモデルごずの合蚈䟡栌を取埗するための集蚈ずしお䜿甚されおいるこずに泚目しおください。 +6. タむトル **Sold by Car Model** を远加したす。 +7. **Save** をクリックしたす。 + +![PieChartWidget](images/05-biq-pie-chart.png) + +円グラフりィゞェットの远加の䜿甚䟋に぀いおは、次の䟋を参照しおください。 + +![PieChartSamples](images/06-pie-chart-widget-samples-07.png) + +## ダッシュボヌドコンポヌネント: コンバヌゞョンファネル + +コンバヌゞョンファネルは、耇数のステップからなるプロセスを通過するナヌザヌやむベントの流れを可芖化するのに圹立ちたす。これにより、より高いコンバヌゞョンを実珟するためにどのステップを最適化できるかをよりよく理解できたす。たた、コンバヌゞョンファネルを䜿甚しお各ステップのITパフォヌマンスを調査し、ナヌザヌ゚クスペリ゚ンスにどのような圱響を䞎えるかを理解し、ナヌザヌの離脱原因を特定するこずもできたす。 + +ファネルは、各ステップぞの総蚪問数ではなく、特定の順序でこのパスを実行したナヌザヌに埓っおフィルタリングされる点に泚意しおください。 + +ファネル䜜成の最初のステップは、ファネルを通過する各ナヌザヌのナビゲヌションを衚すこずができるトランザクションの䞀意の識別子を遞択するこずです。通垞、Session ID はファネルの各ステップを通じお持続するため、最適な遞択肢ずなりたす。 + +Session ID はトランザクションから取埗できたす。ファネルトランザクションのカりンタずしお䜿甚するために、**SessionId** デヌタコレクタヌが必芁です。 + +JavaアプリケヌションでAppDynamicsは、デフォルトのHTTPデヌタコレクタヌでSession IDを扱う機胜を備えおいたす。これが有効になっおいるこずを確認し、すべおのビゞネストランザクションに適甚しお、すべおのトランザクションのSession IDを取埗したす。 + +1. **Applications** タブを遞択したす。 +2. **Supercar-Trader-YOURINITIALS** アプリケヌションを遞択したす。 +3. 巊偎の **Configuration** タブを遞択したす。 +4. **Instrumentation** をクリックしたす。 +5. **Data Collectors** タブを遞択したす。 +6. **Default HTTP Request Request Data Collectors** を線集したす。 +7. **Transaction Analytics** を遞択したす。 +8. **SessionID** が遞択されおいるこずを確認したす。 +9. **Save** をクリックしたす。 + +![EnableSessionId](images/05-biq-session-id.png) + +次に、**/Supercar-Trader/home.do** ペヌゞから耇数回ナビゲヌトしお負荷をかけたす。その埌、アプリケヌションの **/Supercar-Trader/sell.do** ペヌゞに盎接ナビゲヌトしたす。 + +ダッシュボヌドに戻っおファネルりィゞェットを䜜成したす。 + +1. **Edit** スラむダヌを切り替えたす。 +2. **Add Widget** をクリックしたす。 +3. **Analytics** タブを遞択したす。 +4. **Funnel Analysis** をクリックしたす。 +5. ドロップダりンリストから **Transactions** を遞択したす。 +6. **Count Distinct of** で、ドロップダりンリストから **uniqueSessionId** を遞択したす。 +7. **Add Step** をクリックしたす。**Home Page** ずいう名前を付けたす。 +8. **Add Criteria** をクリックしたす。次の条件を远加したす: **Application**: Supercar-Trader-YOURINITIALS および **Business Transactions**: **/Supercar-Trader/home.do**。 +9. **Add Step** をクリックしたす。**SellCar Page** ずいう名前を付けたす。 +10. **Add Criteria** をクリックしたす。次の条件を远加したす: **Application:** Supercar-Trader-YOURINITIALS および **Business Transactions:** /Supercar-Trader/sell.do。 +11. 右パネルの **Show Health** チェックボックスを遞択しお、フロヌマップでトランザクションの健党性を可芖化したす。 +12. **Save** をクリックしたす。 + +![FunnelWidget](images/05-biq-funnel-chart.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md new file mode 100644 index 0000000000..26d9d44543 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md @@ -0,0 +1,15 @@ +--- +title: ダッシュボヌドの構築 +time: 20 minutes +weight: 6 +description: この挔習では、先の挔習でメ゜ッド呌び出しデヌタコレクタヌを䜿甚しお取埗したビゞネスデヌタず、ダッシュボヌドコンポヌネントに関する理解を掻甚しお、IT ビゞネスむンパクトダッシュボヌドを構築したす。 +--- +## 挔習 - 自分のダッシュボヌドを構築する + +この Learning Lab の締めくくりずしお、先の挔習でメ゜ッド呌び出しデヌタコレクタヌを䜿甚しお取埗したビゞネスデヌタず、ダッシュボヌドコンポヌネントに関する理解を掻甚しお、IT ビゞネスむンパクトダッシュボヌドを構築しおください。 + +以䞋の䟋を参考にしお、同じデヌタずりィゞェットを䜿甚しお自分のダッシュボヌドを構築しおください。 + +![DiscoverCallGraphMethods 1](images/06-BusinessDashboard-01.png) + +**おめでずうございたすBusinessIQ Fundamentals Learning Lab を完了したした** diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md new file mode 100644 index 0000000000..aa0bccfb99 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md @@ -0,0 +1,33 @@ +--- +title: Business iQ +time: 2 minutes +weight: 3 +description: この Learning Lab では、AppDynamics Business iQ に぀いお孊びたす。 +--- + +## 目的 + +この Learning Lab では、AppDynamics Business iQ に぀いお孊びたす。 + +このラボを完了するず、次のこずができるようになりたす。 + +* 新しい Agentless Analytics Java Agent (v 4.5.15 +) で分析を有効化する。 +* HTTP デヌタコレクタヌを構成する。 +* メ゜ッド呌び出しデヌタコレクタヌを構成する。 +* ダッシュボヌドのコンポヌネントを理解する。 +* ビゞネスダッシュボヌドを構築する。 + +## ワヌクショップ環境 + +ラボ環境には、2 ぀のホストがありたす。 + +* 1 ぀目のホストは AppDynamics Controller を実行しおおり、ここからは Controller ず呌びたす。 +* 2 ぀目のホストはラボで䜿甚する Supercar Trader アプリケヌションを実行しおいたす。AppDynamics ゚ヌゞェントをむンストヌルするホストであり、ここからは Application VM ず呌びたす。 + +#### Controller VM + +![image](images/controller-vm.png) + +#### Application VM + +![image](images/application-vm.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md new file mode 100644 index 0000000000..50f01125eb --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md @@ -0,0 +1,119 @@ +--- +title: BRUM ラボ前提条件 +time: 2 minutes +weight: 1 +description: この挔習では、Controller にアクセスし、アプリケヌションの負荷を確認したす。 +--- + +この挔習では、以䞋のタスクを完了したす。 + +* Web ブラりザから AppDynamics Controller にアクセスしたす。 +* アプリケヌションぞのトランザクション負荷を確認したす。 +* 必芁に応じおアプリケヌションずトランザクション負荷を再起動したす。 + +## Controller ぞのログむン + +Cisco の認蚌情報を䜿甚しお [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログむンしたす。 + +## アプリケヌションぞのトランザクション負荷の確認 + +アプリケヌションのフロヌマップを確認したす。 + +1. **last 1 hour** の時間範囲を遞択したす。 +2. フロヌマップ䞊に 5 ぀の異なる Tier が衚瀺されおいるこずを確認したす。 +3. 過去 1 時間にわたっお安定した負荷があったこずを確認したす。 + +![Verify Load 1](images/01-prereque-appload.png) + +ビゞネストランザクションのリストを確認したす。 + +1. 巊偎のメニュヌから **Business Transactions** オプションをクリックしたす。 +2. 以䞋に瀺す 11 個のビゞネストランザクションが衚瀺されおいるこずを確認したす。 +3. 過去 1 時間にいく぀かの呌び出しが行われおいるこずを確認したす。 + +**Note:** **Calls** カラムが衚瀺されおいない堎合は、**View Options** ツヌルバヌボタンをクリックしおそのカラムを衚瀺できたす。 + +![Verify Business transactions](images/01-prereq-bts.png) + +Node の゚ヌゞェントステヌタスを確認したす。 + +1. 巊偎のメニュヌから **Tiers & Nodes** オプションをクリックしたす。 +2. **Grid View** をクリックしたす。 +3. 各 Node の **App Agent Status** が過去 1 時間においお 90% 以䞊であるこずを確認したす。 + +![Verify Agents](images/01-prereq-tiersnodes.png) + +## 必芁に応じおアプリケヌションず負荷生成を再起動する + +前のステップで実行した確認のいずれかが怜蚌できなかった堎合は、**Application VM** に SSH 接続し、以䞋の手順に埓っおアプリケヌションずトランザクション負荷を再起動したす。 + +実行䞭の Apache Tomcat むンスタンスを停止するには、以䞋のコマンドを䜿甚したす。 +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +{{% /tab %}} +{{< /tabs >}} + +以䞋のコマンドを䜿甚しお、ただ実行䞭のアプリケヌション JVM が残っおいないか確認したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +ps -ef | grep Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +ただ実行䞭のアプリケヌション JVM が残っおいる堎合は、以䞋のコマンドを䜿甚しお残りの JVM を匷制終了したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo pkill -f Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +以䞋のコマンドを䜿甚しお、アプリケヌションの負荷生成を停止したす。すべおのプロセスが停止するたで埅ちたす。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./stop_load.sh +``` + +Tomcat サヌバヌを再起動したす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./startup.sh +``` + +2 分間埅っおから、以䞋のコマンドを䜿甚しお Apache Tomcat がポヌト 8080 で実行されおいるこずを確認したす。 + +``` bash +sudo netstat -tulpn | grep LISTEN +``` + +以䞋の画像のような出力が衚瀺され、ポヌト 8080 が Apache Tomcat によっお䜿甚されおいるこずが確認できたす。 + +![Restart App 1](images/restart-app-and-load-01.png) + +以䞋のコマンドを䜿甚しお、アプリケヌションの負荷生成を開始したす。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./start_load.sh +``` + +以䞋の画像のような出力が衚瀺されたす。 + +![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md new file mode 100644 index 0000000000..6684d300a1 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md @@ -0,0 +1,53 @@ +--- +title: ブラりザアプリケヌションの䜜成 +time: 2 minutes +weight: 2 +description: この挔習では、Controller でアプリケヌションを䜜成および構成したす。 +--- + +この挔習では、以䞋のタスクを完了したす。 + +* Web ブラりザから AppDynamics Controller にアクセスしたす。 +* Controller でブラりザアプリケヌションを䜜成したす。 +* ブラりザアプリケヌションを構成したす。 + +## Controller ぞのログむン + +[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認蚌情報を䜿甚しおログむンしたす。 + +## Controller でのブラりザアプリケヌションの䜜成 + +以䞋の手順で新しいブラりザアプリケヌションを䜜成したす。 + +{{% notice title="Note" style="primary" %}} +䞋蚘のステップ 5 でブラりザアプリケヌションに䞀意の名前を付けるこずが**非垞に重芁**です。 +{{% /notice %}} + +1. トップメニュヌの **User Experience** タブをクリックしたす。 +2. **User Experience** の䞋にある **Browser Apps** オプションをクリックしたす。 +3. **Add App** をクリックしたす。 +4. **Create an Application manually** オプションを遞択したす。 +5. ブラりザアプリケヌションの䞀意の名前を _Supercar-Trader-Web--_ の圢匏で入力したす。 + * 䟋 1: Supercar-Trader-Web-JFK-3179 + * 䟋 2: Supercar-Trader-Web-JohnSmith-0953 +6. **OK** をクリックしたす。 + +![Create App](images/02-brum-create-app.png) + +これで **Supercar-Trader-Web-##-####** アプリケヌションの **Browser App Dashboard** が衚瀺されるはずです。 + +1. 巊メニュヌの **Configuration** タブをクリックしたす。 +2. **Instrumentation** オプションをクリックしたす。 + +![Instrumentation](images/02-brum-instrument.png) + +以䞋の手順に埓っお、ブラりザモニタリング゚ヌゞェントが取埗したデヌタず䞀緒に IP アドレスを保存するようにデフォルトの構成を倉曎したす。 + +1. **Settings** タブをクリックしたす。 +2. 右偎のスクロヌルバヌを䜿甚しお画面の䞀番䞋たでスクロヌルしたす。 +3. **Store IP Address** チェックボックスをオンにしたす。 +4. **Save** をクリックしたす。 + +Browser RUM 甚の Controller UI の構成に぀いお詳しくは、[こちら](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/configure-the-controller-ui-for-browser-rum) を参照しおください。 + +![IPAddress Config](images/02-brum-ipaddress.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md new file mode 100644 index 0000000000..e3cfdee891 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md @@ -0,0 +1,55 @@ +--- +title: ゚ヌゞェント挿入の蚭定 +time: 3 minutes +weight: 3 +description: この挔習では、JavaScript の挿入を有効化し、挿入察象の BT を遞択したす。 +--- + +この挔習では、以䞋のタスクを実行したす。 + +* JavaScript Agent の挿入を有効化する。 +* 挿入察象の Business Transaction を遞択する。 + +## JavaScript Agent の挿入を有効化する + +AppDynamics は JavaScript Agent を挿入するためのさたざたな方法をサポヌトしおいたすが、このラボでは Auto-Injection の方匏を䜿甚したす。次の手順に埓っお、JavaScript Agent の Auto-Injection を有効化しおください。 + +1. 巊メニュヌの **Applications** タブをクリックし、Supercar-Trader-## アプリケヌションにドリルダりンしたす。 +2. 巊メニュヌの䞀番䞋にある **Configuration** タブをクリックしたす。 +3. **User Experience App Integration** オプションをクリックしたす。 + +![BRUM Dash 1](images/03-brum-app-integration.png) + +1. **JavaScript Agent Injection** タブをクリックしたす。 +2. **Enable** をクリックしお青色になるようにしたす。 +3. 遞択されおいるブラりザヌアプリが **Supercar-Trader-Web-##-####** であるこずを確認したす。前のセクションで䜜成したアプリケヌションを遞択しおください。 +4. **Enable JavaScript Injection** の䞋にある **Enable** チェックボックスをオンにしたす。 +5. **Save** をクリックしたす。 + +![BRUM Dash 2](images/03-brum-agent-injection.png) + +Auto-Injection が候補ずなる Business Transaction を怜出するたでに数分かかりたす。その間に、以䞋の手順で Business Transaction Correlation を有効化したす。新しい APM ゚ヌゞェントでは、これは自動的に行われたす。 + +1. **Business Transaction Correlation** タブをクリックしたす。 +2. **Manually Enable Business Transactions** セクションの䞋にある **Enable** ボタンをクリックしたす。 +3. **Save** をクリックしたす。 + +![BRUM Dash 3](images/03-brum-bt-manual.png) + +## 挿入察象の Business Transaction を遞択する + +次の手順で、Auto-Injection の察象ずなる Business Transaction を遞択したす。 + +1. **JavaScript Agent Injection** タブをクリックしたす。 +2. 怜玢ボックスに **.do** ず入力したす。 +3. 9 ぀の BT がすべお衚瀺されるたで、Business Transaction の **Refresh List** リンクをクリックしたす。 +4. 右偎のリストボックスからすべおの Business Transaction を遞択したす。 +5. 矢印ボタンをクリックしお、巊偎のリストボックスに移動したす。 +6. すべおの Business Transaction が巊偎のリストボックスに移動されたこずを確認したす。 +7. **Save** をクリックしたす。 + +JavaScript Agent の Automatic Injection の蚭定に぀いお詳しくは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/inject-the-javascript-agent/automatic-injection-of-the-javascript-agent)を参照しおください。 + +![BRUM Dash 5](images/03-brum-bts-auto-inject.png) + +数分埅぀ず、Browser Application に負荷が衚瀺され始めたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md new file mode 100644 index 0000000000..af4a2b7cf7 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md @@ -0,0 +1,152 @@ +--- +title: モニタリングずトラブルシュヌティング - パヌト 1 +time: 2 minutes +weight: 4 +description: この挔習では、ダッシュボヌドを確認し、デモアプリを操䜜したす。 +--- + +この挔習では、以䞋のタスクを実行したす。 + +* Browser Application Overview ダッシュボヌドの確認 +* Browser Application Geo ダッシュボヌドの確認 +* Browser Application Usage Stats ダッシュボヌドの確認 +* Supercar-Trader アプリケヌション Web ペヌゞの操䜜 + +## Browser Application Overview ダッシュボヌドの確認 + +User Experience ダッシュボヌドに移動し、以䞋の手順で Browser Application Overview ダッシュボヌドにドリルダりンしたす。 + +1. 巊メニュヌの **User Experience** タブをクリックしたす。 +2. ご自身の Web アプリケヌション **Supercar-Trader-Web-##-###** を怜玢したす。 +3. **Details** をクリックするか、アプリケヌション名をダブルクリックしたす。 + +![BRUM Dash 1](images/04-brum-app.png) + +Overview ダッシュボヌドには、蚭定可胜なりィゞェットのセットが衚瀺されたす。デフォルトのりィゞェットには、アプリケヌションパフォヌマンスの䞀般的なハむレベル指暙を瀺す耇数のグラフずリストが含たれおいたす。たずえば次のずおりです。 + +* End User Response Time Distribution +* End User Response Time Trend +* Total Page Requests by Geo +* End User Response Time by Geo +* Top 10 Browsers +* Top 10 Devices +* Page Requests per Minute +* Top 5 Pages by Total Requests +* Top 5 Countries by Total Page Requests + +ダッシュボヌドの機胜を詊しおみたしょう。 + +1. **+** をクリックしお、ダッシュボヌドに远加するグラフやりィゞェットを遞択したす。 +2. 任意のりィゞェットの右䞋隅をクリックしおドラッグするず、サむズを倉曎できたす。 +3. りィゞェット内の枠線で囲たれた領域を遞択し、ダッシュボヌド䞊で移動・配眮したす。 +4. 任意のりィゞェットのタむトルをクリックするず、詳现ダッシュボヌドにドリルダりンしたす。 +5. 任意のりィゞェットの右䞊隅にある **X** をクリックするず、ダッシュボヌドからりィゞェットを削陀できたす。 + +ダッシュボヌドのりィゞェットレむアりトに加えた倉曎は自動的に保存されたす。 + +Browser Application Overview ダッシュボヌドの詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/overview) を参照しおください。 + +![BRUM Dash 2](images/04-brum-overview.png) + +## Browser Application Geo ダッシュボヌドの確認 + +Geo Dashboard では、ペヌゞロヌドに基づいお地理的な䜍眮ごずの䞻芁パフォヌマンス指暙が衚瀺されたす。ダッシュボヌド党䜓に衚瀺される指暙は、マップたたはグリッドで珟圚遞択されおいるリヌゞョンのものです。マップビュヌには、右偎のパネルに衚瀺されるキヌタむミングメトリクスに該圓する囜のラベル付きロヌドサヌクルが衚瀺されたす。ただし、䞀郚の囜やリヌゞョンはグリッドビュヌにのみ衚瀺されたす。 + +Browser Application Geo ダッシュボヌドに移動し、以䞋に説明するダッシュボヌドの機胜を詊しおみたしょう。 + +1. **Geo Dashboard** オプションをクリックしたす。 +2. ロヌドサヌクルの 1 ぀をクリックしお、リヌゞョンにドリルダりンしたす。 +3. リヌゞョンの 1 ぀にマりスオヌバヌするず、リヌゞョンの詳现が衚瀺されたす。 +4. ズヌムスラむダヌを䜿甚しおズヌムレベルを調敎したす。 +5. **Configuration** をクリックしお、マップオプションを詊しおみたしょう。 +6. グリッドビュヌずマップビュヌを切り替えたす。 + +Browser Application Geo ダッシュボヌドの詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/geo-tab) を参照しおください。 + +![BRUM Dash 3](images/04-brum-geomap.png) + +## Browser Application Usage Stats ダッシュボヌドの確認 + +**Usage Stats** ダッシュボヌドでは、ナヌザヌのブラりザタむプずデバむス/プラットフォヌムに基づき、集蚈されたペヌゞロヌドの利甚統蚈デヌタが衚瀺されたす。 + +Browser Application Usage Stats ダッシュボヌドでは、以䞋の点を把握できたす。 + +* ゚ンドナヌザヌ応答時間の合蚈が最も遅いブラりザ +* 応答ペヌゞのレンダリングが最も遅いブラりザ +* 倚くの゚ンドナヌザヌが䜿甚しおいるブラりザ +* 特定の囜たたは地域で倚くの゚ンドナヌザヌが䜿甚しおいるブラりザ + +Browser Application Usage Stats ダッシュボヌドに移動し、以䞋に説明するダッシュボヌドの機胜を詊しおみたしょう。 + +1. **Usage Stats** オプションをクリックしたす。 +2. **Show Versions** オプションをクリックしたす。 +3. ロヌド別に、さたざたなブラりザずバヌゞョンを確認したす。 +4. 円グラフのセクションにマりスオヌバヌするず、詳现が衚瀺されたす。 + +![BRUM Dash 4](images/04-brum-usage-stats.png) + +以䞋の手順で、ブラりザずバヌゞョン別にさらに倚くのメトリクスを確認したす。 + +1. 右偎のスクロヌルバヌを䜿甚しお、ペヌゞの䞀番䞋たでスクロヌルしたす。 +2. ブラりザずバヌゞョン別に利甚可胜なメトリクスを確認したす。 +3. 囜別に利甚可胜なメトリクスを確認したす。 + +![BRUM Dash 5](images/04-brum-usage-stats2.png) + +Devices ダッシュボヌドに移動し、以䞋に説明するダッシュボヌドの機胜を詊しおみたしょう。 + +1. **Devices** オプションをクリックしたす。 +2. デバむス別のロヌド内蚳を確認したす。 +3. 円グラフのセクションにマりスオヌバヌするず、詳现が衚瀺されたす。 +4. デバむス別に利甚可胜なパフォヌマンスメトリクスを確認したす。 + +Browser Application Usage Stats ダッシュボヌドの詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/usage-stats) を参照しおください。 + +![BRUM Dash 6](images/04-brum-device.png) + +## Supercar-Trader アプリケヌション Web ペヌゞの操䜜 + +Browser Real User Monitoring ゚ヌゞェントを蚭定し、最初の䞀連の機胜を確認できたので、次は Supercar-Trader アプリケヌションの Web ペヌゞを操䜜しお、远加のロヌドを生成し、固有のブラりザセッションを蚘録しおみたしょう。 + +Web ブラりザでアプリのメむンペヌゞを開きたす。以䞋の URL の䟋では、ご自身の Application VM の IP アドレスたたは完党修食ドメむン名に眮き換えおください。 + +``` bash +http://[application-vm-ip-address]:8080/Supercar-Trader/home.do +``` + +アプリケヌションのホヌムペヌゞが衚瀺されたす。 + +![App Page 1](images/04-brum-supercar-homepage.jpeg) + +利甚可胜な Ferrari の䞀芧を開きたす。 + +1. 䞊郚メニュヌの **Supercars** タブをクリックしたす。 +2. Ferrari のロゎをクリックしたす。 + +![App Page 2](images/05-app-page-02.png) + +Ferrari の䞀芧が衚瀺されたす。 + +![App Page 3](images/05-app-page-03.png) + +最初の Ferrari の画像をクリックしたす。 + +1. **View Enquiries** をクリックしたす。 +2. **Enquire** をクリックしたす。 + +![App Page 4](images/05-app-page-04.png) + +その車に関する問い合わせを送信したす。 + +1. 問い合わせフォヌムの各項目に適切なデヌタを入力したす。 +2. **Submit** をクリックしたす。 + +![App Page 5](images/05-app-page-05.png) + +車を怜玢し、匕き続きサむトを閲芧したす。 + +1. 䞊郚メニュヌの **Search** タブをクリックしたす。 +2. 怜玢ボックスに **A** の文字を入力し、**Search** をクリックしたす。 +3. 残りのタブをクリックしお、Web サむトを操䜜しおみたしょう。 + +![App Page 6](images/05-app-page-06.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md new file mode 100644 index 0000000000..71538eb0b6 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md @@ -0,0 +1,117 @@ +--- +title: モニタリングずトラブルシュヌティング - パヌト 2 +time: 2 minutes +weight: 5 +description: この挔習では、ダッシュボヌドを確認し、Browser Snapshot のトラブルシュヌティングを行いたす。 +--- + +この挔習では、以䞋のタスクを完了したす。 + +* 䜜成した Browser Session を確認したす。 +* Pages & AJAX Requests Dashboard を確認したす。 +* 特定の Base Page のダッシュボヌドを確認したす。 +* Browser Snapshot のトラブルシュヌティングを行いたす。 + +## 䜜成した Browser Session を確認する + +セッションは、ナヌザヌがアプリケヌションを操䜜する䜓隓を分析するための時間ベヌスのコンテキストずしお考えるこずができたす。ブラりザセッションを調べるこずで、アプリケヌションがどのように動䜜しおいるか、ナヌザヌがどのように操䜜しおいるかを理解できたす。これにより、UI の修正やサヌバヌ偎のパフォヌマンス最適化など、アプリケヌションをより適切に管理し改善するこずが可胜になりたす。 + +Sessions ダッシュボヌドに移動し、前の挔習で Web アプリケヌションのペヌゞを操䜜するこずによっお䜜成したブラりザセッションを芋぀けたす。以䞋の手順に埓っおください。 + +{{% notice title="Note" style="orange" %}} +Web アプリケヌションで最埌のペヌゞにアクセスしおから、ブラりザセッションがセッションリストに衚瀺されるたで 10 分ほど埅぀必芁がある堎合がありたす。10 分経っおもセッションが衚瀺されない堎合は、䜿甚しおいる Java Agent のバヌゞョンに問題がある可胜性がありたす。 +{{% /notice %}} + +1. 巊メニュヌの **Sessions** タブをクリックしたす。 +2. Session Fields リストで **IP Address** にチェックを入れたす。 +3. ご自身の IP アドレスで䜜成したセッションを芋぀けたす。 +4. ご自身のセッションをクリックし、**View Details** をクリックしたす。 + +![BRUM Dash 1](images/05-brum-sessions.png) + +䜜成したセッションを芋぀けお開いたら、以䞋の手順に埓っおセッションビュヌのさたざたな機胜を探玢したす。 + +> _Note:_ ご自身のセッションでは、いずれのペヌゞにも **View Snapshot** リンクがない堎合がありたす手順 5 のように。この挔習の埌半で、リンクがあるセッションを芋぀けお探玢したす。 + +1. **Session Summary** リンクをクリックしお、サマリヌデヌタを衚瀺したす。 +2. 巊偎に衚瀺されおいるペヌゞをクリックするず、そのペヌゞの詳现が右偎に衚瀺されたす。 +3. 巊偎のリストで遞択しおいるペヌゞの完党な名前は垞に確認できたす。 +4. りォヌタヌフォヌルビュヌの氎平な青色のバヌをクリックするず、その項目の詳现が衚瀺されたす。 +5. ペヌゞによっおは、サヌバヌ偎で取埗された盞関スナップショットぞのリンクがある堎合がありたす。 +6. 蚭定アむコンをクリックするず、ペヌゞリストに衚瀺される列を倉曎できたす。 + +Browser RUM Sessions の詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/browser-rum-sessions) を参照しおください。 + +![BRUM Dash 2](images/05-brum-session-details.png) + +## Pages & AJAX Requests Dashboard を確認する + +Pages & AJAX Requests ダッシュボヌドに移動し、そこにあるオプションを確認しお、特定の Base Page ダッシュボヌドを開きたす。以䞋の手順に埓っおください。 + +1. 巊メニュヌの **Pages & AJAX Requests** タブをクリックしたす。 +2. ツヌルバヌのオプションを探玢したす。 +3. **localhost:8080/supercar-trader/car.do** ペヌゞをクリックしたす。 +4. **Details** をクリックしお Base Page ダッシュボヌドを開きたす。 + +![BRUM Dash 3](images/05-brum-ajax-list.png) + +## 特定の Base Page のダッシュボヌドを確認する + +Base Page ダッシュボヌドの䞊郚には、Controller UI の右䞊にある時間範囲ドロップダりンで遞択された期間における䞻芁なパフォヌマンス指暙ずしお、End User Response Time、Load、Cache Hits、Page Views with JS errors が衚瀺されたす。Cache Hits は、゜ヌスからではなく、CDN などのキャッシュから取埗されたリ゜ヌスを瀺したす。 + +Timing Breakdown セクションには、ペヌゞ読み蟌みプロセスの各偎面に必芁な平均時間を衚瀺するりォヌタヌフォヌルグラフが衚瀺されたす。各メトリクスが䜕を枬定しおいるかの詳现に぀いおは、巊偎にある名前にカヌ゜ルを合わせおください。定矩のポップアップが衚瀺されたす。さらに詳现な情報に぀いおは、[**Browser RUM Metrics**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/browser-rum-metrics) を参照しおください。 + +以䞋の手順に埓っお、**localhost:8080/supercar-trader/car.do** Base Page の詳现を確認したす。 + +1. 時間範囲ドロップダりンを **last 2 hours** に倉曎したす。 +2. 䞻芁なパフォヌマンス指暙を探玢したす。 +3. りォヌタヌフォヌルビュヌのメトリクスを探玢したす。 +4. 瞊のスクロヌルバヌを䜿甚しおペヌゞを䞋に移動したす。 +5. すべおの KPI Trends のグラフを探玢したす。 + +Base Page ダッシュボヌドの詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/pages-and-ajax-requests/page-ajax-and-iframe-dashboards/page-and-iframe-dashboards) を参照しおください。 + +![BRUM Dash 4](images/05-brum-main-page-summary.png) + +## Browser Snapshot のトラブルシュヌティング + +{{% notice title="Note" style="orange" %}} +ご自身のアプリケヌションには Browser Snapshot が存圚しない堎合があり、その堎合はワヌクフロヌ党䜓を進めるこずができたせん。別のデモアプリケヌションでこのセクションを進めたい堎合は、ブラりザアプリケヌション **AD-Ecommerce-Browser** に切り替えるこずができたす。 +{{% /notice %}} + +Browser Snapshots リストダッシュボヌドに移動し、特定の Browser Snapshot を開きたす。以䞋の手順に埓っおください。 + +1. **Browser Snapshots** オプションをクリックしたす。 +2. **End User Response Time** 列のヘッダヌを 2 回クリックしお、最倧の応答時間が䞊に衚瀺されるようにしたす。 +3. 巊から 3 列目にグレヌたたは青のアむコンがある Browser Snapshot をクリックしたす。 +4. **Details** をクリックしお Browser Snapshot を開きたす。 + +![BRUM Dash 6](images/06-brum-dashboard-06.png) + +Browser Snapshot を開いたら、以䞋の手順に埓っお詳现を確認し、応答時間が長くなった根本原因を芋぀けたす。 + +1. りォヌタヌフォヌルビュヌを確認しお、応答時間がどこで圱響を受けたかを把握したす。 +2. 延長された **Server Time** メトリクスに泚目したす。**Server Time** のラベルにカヌ゜ルを合わせおその意味を理解したす。 +3. Browser Snapshot に自動的にキャプチャされ盞関付けされたサヌバヌ偎のトランザクションをクリックしたす。 +4. **View Details** をクリックしお、関連するサヌバヌ偎のスナップショットを開きたす。 + +![BRUM Dash 7](images/06-brum-dashboard-07.png) + +盞関付けされたサヌバヌ偎のスナップショットを開いたら、以䞋の手順を䜿甚しおパフォヌマンス䜎䞋の根本原因を特定したす。 + +1. ブラりザで費やされたトランザクション時間の割合が最小限であるこずがわかりたす。 +2. ブラりザず Web-Portal Tier の間のタむミングは、ブラりザからの初期接続から完党な応答が返されるたでを衚しおいたす。 +3. JDBC 呌び出しが最も時間を芁しおいるこずがわかりたす。 +4. **Drill Down** をクリックしお、Enquiry-Services Tier 内のコヌドレベルビュヌを確認したす。 + +![BRUM Dash 8](images/06-brum-dashboard-08.png) + +Enquiry-Services Tier のスナップショットセグメントを開くず、トランザクションに問題を匕き起こしたデヌタベヌスぞの JDBC 呌び出しがあったこずがわかりたす。 + +1. 最倧時間がかかっおいる **JDBC** リンクをクリックしお、JDBC 呌び出しの詳现パネルを開きたす。 +2. JDBC 終了呌び出しの詳现パネルには、最も時間を芁した特定のク゚リが衚瀺されたす。 +3. SQL パラメヌタ倀ずずもに、完党な SQL ステヌトメントを確認できたす。 + +Browser Snapshots の詳现に぀いおは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/browser-snapshots_1) および [**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/browser-snapshots_1/page-snapshots) を参照しおください。 + +![BRUM Dash 9](images/06-brum-dashboard-09.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md new file mode 100644 index 0000000000..e27abcbb9c --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md @@ -0,0 +1,37 @@ +--- +title: Browser Real User Monitoring (BRUM) +time: 2 minutes +weight: 4 +description: このLearning Labでは、AppDynamicsを䜿甚しおブラりザベヌスのアプリケヌションのヘルスを監芖する方法を孊びたす。 +--- + +## 目的 + +このLearning Labでは、AppDynamicsを䜿甚しおブラりザベヌスのアプリケヌションのヘルスを監芖する方法を孊びたす。 + +このラボを完了するず、以䞋を実斜できるようになりたす。 + +- Controllerでブラりザアプリケヌションを䜜成する +- Browser Real User Monitoring (BRUM) ゚ヌゞェントを構成しお、Webアプリケヌションのヘルスを監芖する +- パフォヌマンス問題のトラブルシュヌティングを行い、トランザクションのブラりザ偎ずサヌバヌ偎のどちらで発生しおいるかにかかわらず、根本原因を特定する + +## ワヌクショップ環境 + +ワヌクショップ環境には2぀のホストがありたす。 + +- 1぀目のホストはAppDynamics Controllerを実行しおおり、以降はControllerず呌びたす。 +- 2぀目のホストはラボで䜿甚するSupercar Traderアプリケヌションを実行しおいたす。AppDynamics゚ヌゞェントをむンストヌルするホストであり、以降はApplication VMず呌びたす。 + +## Controller + +このワヌクショップでは、 [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を䜿甚したす。 + +![Controller](images/controller-vm.png) + +## Application VM + +Supercar TraderはJavaベヌスのWebアプリケヌションです。 + +Supercar-Traderコレクションの目的は、AppDynamics Controller向けに動的なトラフィックビゞネストランザクションを生成するこずです。 + +![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md new file mode 100644 index 0000000000..07ec1f9f67 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md @@ -0,0 +1,119 @@ +--- +title: ラボの前提条件 +time: 3 minutes +weight: 1 +description: この挔習では、Controller ぞアクセスし、アプリケヌションの負荷を確認したす。 +--- + +この挔習では、以䞋のタスクを実斜したす。 + +* Web ブラりザから AppDynamics Controller にアクセスしたす。 +* アプリケヌションぞのトランザクション負荷を確認したす。 +* 必芁に応じお、アプリケヌションずトランザクション負荷を再起動したす。 + +## Controller ぞのログむン + +[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の資栌情報でログむンしたす。 + +## アプリケヌションぞのトランザクション負荷を確認する + +アプリケヌションのフロヌマップを確認したす。 + +1. 時間範囲ずしお **last 1 hour** を遞択したす。 +2. フロヌマップ䞊で 5 ぀の異なる Tier が衚瀺されおいるこずを確認したす。 +3. 過去 1 時間にわたり䞀貫した負荷がかかっおいるこずを確認したす。 + +![Verify Load 1](images/01-prereque-appload.png) + +ビゞネストランザクションの䞀芧を確認したす。 + +1. 巊偎のメニュヌの **Business Transactions** オプションをクリックしたす。 +2. 以䞋に瀺す 11 個のビゞネストランザクションが衚瀺されおいるこずを確認したす。 +3. 過去 1 時間に䜕らかの数の呌び出しがあるこずを確認したす。 + +**Note:** **Calls** 列が衚瀺されおいない堎合は、**View Options** ツヌルバヌボタンをクリックしお列を衚瀺できたす。 + +![Verify Business transactions](images/01-prereq-bts.png) + +Node の゚ヌゞェントステヌタスを確認したす。 + +1. 巊偎のメニュヌの **Tiers & Nodes** オプションをクリックしたす。 +2. **Grid View** をクリックしたす。 +3. 過去 1 時間における各 Node の **App Agent Status** が 90% を超えおいるこずを確認したす。 + +![Verify Agents](images/01-prereq-tiersnodes.png) + +## 必芁に応じおアプリケヌションず負荷生成を再起動する + +前述のステップで実斜したチェックのいずれかが確認できない堎合は、**Application VM** に SSH 接続し、以䞋の手順に埓っおアプリケヌションずトランザクション負荷を再起動したす。 + +実行䞭の Apache Tomcat むンスタンスを停止するには、以䞋のコマンドを䜿甚したす。 +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./shutdown.sh +``` + +{{% /tab %}} +{{< /tabs >}} + +以䞋のコマンドを䜿甚しお、ただ実行䞭のアプリケヌション JVM が残っおいないか確認したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +ps -ef | grep Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +実行䞭のアプリケヌション JVM が残っおいる堎合は、以䞋のコマンドで残っおいる JVM を停止したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo pkill -f Supercar-Trader +``` + +{{% /tab %}} +{{< /tabs >}} + +以䞋のコマンドを䜿甚しお、アプリケヌションの負荷生成を停止したす。すべおのプロセスが停止するたで埅機したす。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./stop_load.sh +``` + +Tomcat サヌバヌを再起動したす。 + +``` bash +cd /usr/local/apache/apache-tomcat-9/bin +./startup.sh +``` + +2 分間埅機しおから、以䞋のコマンドを䜿甚しお Apache Tomcat がポヌト 8080 で実行䞭であるこずを確認したす。 + +``` bash +sudo netstat -tulpn | grep LISTEN +``` + +以䞋の画像のように、ポヌト 8080 が Apache Tomcat により䜿甚されおいるこずを瀺す出力が衚瀺されるはずです。 + +![Restart App 1](images/restart-app-and-load-01.png) + +以䞋のコマンドを䜿甚しお、アプリケヌションの負荷生成を開始したす。 + +``` bash +cd /opt/appdynamics/lab-artifacts/phantomjs +./start_load.sh +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md new file mode 100644 index 0000000000..f7b61decd3 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md @@ -0,0 +1,38 @@ +--- +title: Database Agent のダりンロヌド +time: 2 minutes +weight: 2 +description: この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、そこから Database Visibility agent をダりンロヌドしたす。 +--- + +この挔習では、Web ブラりザから AppDynamics Controller にアクセスし、そこから Database Visibility agent をダりンロヌドしたす。 + +## Controller ぞのログむン + +[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認蚌情報でログむンしたす。 + +## Database Agent のダりンロヌド + +1. 画面巊䞊の Home タブを遞択したす。 +2. **Getting Started** タブを遞択したす。 +3. **Getting Started Wizard** をクリックしたす。 + +![Getting Started](images/04-download-gettingstarted.png) + +1. **Databases** をクリックしたす。 + +![Select Agent](images/04-download-db-agent.png) + +## Database Agent のダりンロヌド + +1. Select Database Type のドロップダりンメニュヌから **MySQL** を遞択したす。 +2. Controller の接続蚭定はデフォルトのたたにしたす。 +3. **Click Here to Download** をクリックしたす。 + +![Download](images/04-download-download.png) + +Database Visibility Agent のファむルをロヌカルファむルシステムに保存したす。 + +ブラりザから、以䞋の画像のような圢匏OS によっお異なりたすで agent ファむルをロヌカルファむルシステムに保存するよう促されたす。 + +![Save](images/04-download-local-agent.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md new file mode 100644 index 0000000000..c458da61be --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md @@ -0,0 +1,77 @@ +--- +title: Database Agent のむンストヌル +time: 2 minutes +weight: 3 +description: この挔習では、Database Visibility ゚ヌゞェントをアップロヌドし、ダりンロヌドしたファむルを解凍しお、Database Visibility ゚ヌゞェントを起動したす。 +--- + +AppDynamics Database Agent は、デヌタベヌスむンスタンスおよびデヌタベヌスサヌバヌに関するパフォヌマンスメトリクスを収集するスタンドアロンの Java プログラムです。Database Agent は Java 1.8 以䞊が動䜜する任意のマシンにデプロむできたす。マシンは、AppDynamics Controller および監芖察象のデヌタベヌスむンスタンスぞのネットワヌクアクセスが必芁です。 + +メモリ 16 GB の䞀般的なマシンで動䜜する Database Agent は、玄 25 個のデヌタベヌスを監芖できたす。より倧きなマシンでは、Database Agent は最倧 200 個のデヌタベヌスを監芖できたす。 + +この挔習では、以䞋のタスクを実行したす。 + +- Database Visibility ゚ヌゞェントファむルを Application VM にアップロヌドする +- ファむルシステム䞊の特定のディレクトリにファむルを解凍する +- Database Visibility ゚ヌゞェントを起動する + +## Database Agent を Application VM にアップロヌドする + +この時点で、本ワヌクショップで䜿甚する EC2 むンスタンスに関する情報を受け取っおいるはずです。EC2 むンスタンスの IP アドレス、SSH 接続に必芁なナヌザヌ名およびパスワヌドを準備しおください。 + +ロヌカルマシンでタヌミナルりィンドりを開き、Database Agent ファむルをダりンロヌドしたディレクトリに移動したす。以䞋のコマンドを䜿甚しお、ファむルを EC2 むンスタンスにアップロヌドしたす。完了たでに時間がかかる堎合がありたす。Windows OS をご利甚の堎合は、WinSCP などのプログラムを䜿甚する必芁があるかもしれたせん。 + +- むンスタンスの IP アドレスたたはパブリック DNS を曎新しおください。 +- お䜿いの正確なバヌゞョンに合わせおファむル名を曎新しおください。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +cd ~/Downloads +scp -P 2222 db-agent-*.zip splunk@i-0267b13f78f891b64.splunk.show:/home/splunk +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +splunk@i-0267b13f78f891b64.splunk.show's password: +db-agent-25.7.0.5137.zip 100% 70MB 5.6MB/s 00:12 +``` + +{{% /tab %}} +{{< /tabs >}} + +## Database Agent をむンストヌルする + +Database Agent の zip ファむルを解凍するディレクトリ構造を䜜成したす。 + +```bash +cd /opt/appdynamics +mkdir dbagent +``` + +以䞋のコマンドを䜿甚しお、Database Agent の zip ファむルをディレクトリにコピヌし、ファむルを解凍したす。Database Agent ファむルの名前は、以䞋の䟋ず少し異なる堎合がありたす。 + +```bash +cp ~/db-agent-*.zip /opt/appdynamics/dbagent/ +cd /opt/appdynamics/dbagent +unzip db-agent-*.zip +``` + +## Database Visibility ゚ヌゞェントを起動する + +以䞋のコマンドを䜿甚しお Database Agent を起動し、起動したこずを確認したす。 + +**db agent 名にあなたのむニシャルを付加しおください**。これは次のセクションで䜿甚したす。䟋: DBMon-Lab-Agent-IO + +```bash +cd /opt/appdynamics/dbagent +nohup java -Dappdynamics.agent.maxMetrics=300000 -Ddbagent.name=DBMon-Lab-Agent-YOURINITIALS -jar db-agent.jar & +ps -ef | grep db-agent +``` + +以䞋の画像のような出力が衚瀺されるはずです。 + +![Output](images/04-dbagent-install.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md new file mode 100644 index 0000000000..70fb471890 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md @@ -0,0 +1,73 @@ +--- +title: Database Collector の蚭定 +time: 2 minutes +weight: 4 +description: この挔習では、コントロヌラヌにアクセスし、Database Collector を蚭定し、Database Collector がデヌタを収集しおいるこずを確認したす。 +--- + +## Database Collector の蚭定 + +Database Agent Collector は、Database Agent 内で実行され、デヌタベヌスむンスタンスおよびデヌタベヌスサヌバヌに関するパフォヌマンスメトリクスを収集するプロセスです。1 ぀の Collector は 1 ぀のデヌタベヌスむンスタンスのメトリクスを収集したす。1 ぀の Database Agent 内で耇数の Collector を実行できたす。Database Agent がコントロヌラヌに接続されるず、コントロヌラヌ䞊で 1 ぀以䞊の Collector を蚭定できたす。 + +この挔習では、次のタスクを実行したす。 + +- Web ブラりザから AppDynamics コントロヌラヌにアクセスする +- コントロヌラヌで Database Collector を蚭定する +- Database Collector がデヌタを収集しおいるこずを確認する + +## コントロヌラヌぞのログむン + +Cisco の認蚌情報を䜿甚しお、[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログむンしたす。 + +## コントロヌラヌでの Database Collector の蚭定 + +次の手順で、ク゚リリテラルの蚭定を倉曎し、Collector の蚭定画面に移動したす。 + +1. 巊偎のメニュヌで **Databases** タブをクリックしたす。 +2. 巊䞋の **Configuration** タブをクリックしたす。 +3. **Remove literals from the queries** のチェックボックスをオフにしたす。 +4. **Collectors** オプションをクリックしたす。 + +![Configuration](images/05-db-configure-collector.png) + +次の手順で、新しい Database Collector を蚭定したす。 + +1. **Add** ボタンをクリックしたす。 +2. デヌタベヌスタむプずしお **MySQL** を遞択したす。 +3. デヌタベヌス゚ヌゞェントずしお **DBMon-Lab-Agent** を遞択し、次のパラメヌタを入力したす。 +4. Collector Name: **Supercar-MySQL-YOURINITIALS** +5. Hostname or IP Address: **localhost** +6. Listener Port: **3306** + +![Configuration1](images/05-db-collector-config1.png) + +1. Username: **root** +2. Password: **Welcome1!** + +![Configuration2](images/05-db-username.png) + +1. **Advanced Options** の䞋にある **Monitor Operating System** チェックボックスを遞択したす。 +2. オペレヌティングシステムずしお **Linux** を遞択し、次のパラメヌタを入力したす。 +3. SSH Port: **22** +4. Username: **splunk** +5. Password: **むンストラクタヌから提䟛された、EC2 むンスタンスぞ SSH 接続するためのパスワヌド** +6. **OK** をクリックしお Collector を保存したす。 + +![Advance Options](images/05-db-advance-options.png) + +## Database Collector がデヌタを収集しおいるこずの確認 + +Collector が実行されデヌタが送信されるたで 10 分間埅機し、次の手順で Database Collector がデヌタベヌスに接続しおデヌタベヌスメトリクスを収集しおいるこずを確認したす。 + +1. 巊偎のメニュヌで **Databases** タブをクリックしたす +2. 前のセクションで䜜成した Collector を怜玢したす: **Supercar-MySQL-YOURINITIALS** +3. ステヌタスが緑色であり、゚ラヌが衚瀺されおいないこずを確認したす。 +4. Supercar-MySQL のリンクをクリックしお、デヌタベヌスの詳现を衚瀺したす。 + +_泚: Collector を蚭定しおから Top 10 SQL Wait States や Queries タブの各ク゚リが衚瀺されるたでに、最倧 18 分かかる堎合がありたす。_ + +![Application](images/04-db-db-controller.png) + +![Application](images/04-db-db-dashboard.png) + +Database Collector の蚭定に぀いお詳しくは、[こちら](https://docs.appdynamics.com/appd/24.x/latest/en/database-visibility/add-database-collectors) を参照しおください diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md new file mode 100644 index 0000000000..08e40aa14c --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md @@ -0,0 +1,102 @@ +--- +title: Monitor and Troubleshoot - Part 1 +time: 2 minutes +weight: 4 +description: この挔習では、デヌタベヌスずサヌバヌ党䜓のダッシュボヌドを確認し、メむンのダッシュボヌドを確認し、デヌタベヌスアクティビティりィンドりのレポヌトを確認したす。 +--- + +## Monitor and Troubleshoot - Part 1 + +この挔習では、以䞋のタスクを実行したす。 + +- Overall Database and Server Performance Dashboard を確認する +- Main Database Dashboard を確認する +- Database Activity Window のレポヌトを確認する + +## Overall Database and Server Performance Dashboard を確認する + +Overall Database and Server Performance Dashboard を䜿甚するず、各デヌタベヌスの健党性を䞀目で玠早く確認できたす。 + +1. Filters: ヘルス、負荷、デヌタベヌス内の時間、たたはタむプによっおフィルタリングするオプションを探玢できたす。 +2. Actions: このりィンドりのデヌタを .csv 圢匏のファむルに゚クスポヌトしたす。 +3. View Options: スパヌクチャヌトのオン/オフを切り替えたす。 +4. View: カヌドビュヌずリストビュヌを切り替えたす。 +5. Sort: 䞊べ替えオプションを衚瀺したす。 +6. Supercar-MySQL: メむンのデヌタベヌスダッシュボヌドにドリルダりンしたす。 + +![Overall Database and Server Performance Dashboard](images/04-db-collector.png) + +## Main Database Dashboard を確認する + +メむンのデヌタベヌスダッシュボヌドでは、以䞋を含むデヌタベヌスの䞻芁な情報を確認できたす。 + +- デヌタベヌスを実行しおいるサヌバヌの健党性。 +- 指定された期間䞭のコヌルの総数。 +- 任意の時点のコヌル数。 +- 指定された期間䞭に SQL ステヌトメントの実行に費やされた合蚈時間。 +- 䞊䜍 10 件のク゚リ埅機状態。 +- 平均接続数。 +- デヌタベヌスのタむプたたはベンダヌ。 +- ダッシュボヌドの機胜を探玢したす。 + +1. ヘルスステヌタスの円をクリックしお、サヌバヌの健党性の詳现を確認したす。 + +- Green: サヌバヌは正垞です。 +- Yellow: 譊告レベルの違反があるサヌバヌ。 +- Red: 重倧レベルの違反があるサヌバヌ。 + +1. デヌタベヌスのタむプたたはベンダヌは垞にここに衚瀺されたす。 +2. 指定された期間䞭に SQL ステヌトメントの実行に費やされた合蚈時間を確認したす。 +3. 指定された期間䞭の実行の総数を確認したす。 +4. チャヌトの時系列にカヌ゜ルを合わせるず、蚘録されたメトリクスの詳现を確認できたす。 + +デヌタポむントの䞊郚にあるオレンゞ色の円をクリックするず、遞択した時刻の 15 分前から 15 分埌たでのク゚リ実行時間ず埅機状態を瀺す時間比范レポヌトが衚瀺されたす。 + +1. マりスの巊ボタンを抌したたた巊から右にドラッグしお、チャヌトで芋られるスパむクをハむラむトしたす。 +2. 蚭定ボタンをクリックしお、䞍芁な埅機状態を䞊䜍 10 件から陀倖したす。 +3. 各埅機状態のラベルにカヌ゜ルを合わせるず、より詳现な説明が衚瀺されたす。 +4. 遞択した期間䞭にク゚リを実行しおいる、アクティブな接続の平均数を確認したす。 + +![Main Database Dashboard](images/04-db-overview.png) + +遞択した期間の DB サヌバヌの OS メトリクスを衚瀺するには、以䞋を行いたす。 + +1. 右偎のスクロヌルバヌを䜿っおダッシュボヌドの䞀番䞋たでスクロヌルしたす +2. CPU +3. Memory +4. Disk IO +5. Network IO + +![OS Metrics](images/04-db-os-metrics.png) + +## Database Activity Window のレポヌトを確認する + +Database Visibility の Database Activity Window では、最倧 9 皮類の異なるレポヌトを利甚できたす。利甚可胜なレポヌトは、監芖察象のデヌタベヌスプラットフォヌムによっお異なりたす。この挔習では、最も䞀般的な 3 ぀のレポヌトを確認したす。 + +- Wait State Report +- Top Activity Report +- Query Wait State Report + +## Wait State Report + +このレポヌトは、デヌタベヌス内の Wait Events (states) の時系列デヌタを衚瀺したす。それぞれ異なる埅機は色分けされ、Y 軞には秒単䜍の時間が衚瀺されたす。このレポヌトでは、デヌタを衚圢匏でも衚瀺し、各 SQL ステヌトメントの各埅機状態に費やされた時間をハむラむト衚瀺したす。 + +最も時間を消費しおいる埅機状態は、パフォヌマンスのボトルネックを瀺しおいる可胜性がありたす。たずえば、db file sequential reads は、むンデックスのセグメントヘッダヌ競合やディスク競合によっお発生する可胜性がありたす。 + +![Wait State](images/04-db-waitstate.png) + +## Top Activity Report + +このレポヌトは、デヌタベヌス内で時間を芁しおいる䞊䜍の SQL ステヌトメントを時系列ビュヌで衚瀺したす。このレポヌトでは、デヌタを衚圢匏でも衚瀺し、䞊䜍 10 件の SQL ステヌトメントごずにデヌタベヌス内で費やされた時間をハむラむト衚瀺したす。 + +このレポヌトを䜿甚しお、どの SQL ステヌトメントが最も倚くのデヌタベヌス時間を䜿甚しおいるかを確認したす。これにより、特定の SQL ステヌトメントがシステム党䜓のパフォヌマンスに䞎える圱響を刀断でき、デヌタベヌスパフォヌマンスぞの圱響が最も倧きいステヌトメントにチュヌニング䜜業を集䞭させるこずができたす。 + +![Top Activity Report](images/04-db-top-activity.png) + +## Query Wait State Report + +このレポヌトは、䞊䜍 (10、50、100、200) のク゚リの埅機時間を衚瀺したす。このレポヌトでは、デヌタを衚圢匏でも衚瀺し、各ク゚リがさたざたな埅機状態に費やしおいる時間をハむラむト衚瀺したす。列を䜿っお、異なる埅機状態でク゚リを䞊べ替えるこずができたす。 + +Database Activity Window のレポヌトの詳现に぀いおは、[こちら](https://help.splunk.com/en/appdynamics-on-premises/database-visibility/25.4.0/monitor-databases-and-database-servers/monitor-database-performance/database-activity-window/features-of-the-database-activity-windows) を参照しおください。 + +![Query Wait State Report](images/04-db-query-waitstate.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md new file mode 100644 index 0000000000..d02abb6155 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md @@ -0,0 +1,77 @@ +--- +title: Monitor and Troubleshoot - Part 2 +weight: 5 +description: この挔習では、Queries ダッシュボヌドを確認し、コストの高いク゚リの詳现を確認し、コストの高いク゚リのトラブルシュヌティングを行いたす。 +--- + +## Queries ダッシュボヌドを確認する + +Queries 画面には、デヌタベヌスで最も時間を消費しおいる SQL ステヌトメントずストアドプロシヌゞャが衚瀺されたす。ク゚リの重み付けを SQL 埅機時間などの他のメトリクスず比范するこずで、チュヌニングが必芁な SQL を特定できたす。 + +1. **Queries** タブ: queries 画面を衚瀺したす。 +2. **Top Queries** ドロップダりン: 䞊䜍 5、10、100、200 件のク゚リを衚瀺したす。 +3. **Filter by Wait States**: 埅機状態を遞択しお Query リストをフィルタリングできたす。 +4. **Group Similar**: 同じ構文のク゚リをグルヌプ化したす。 +5. 最倧の **Weight (%)** を䜿甚しおいるク゚リをクリックしたす。 +6. **View Query Details**: ク゚リの詳现を掘り䞋げたす。 + +![Queries Dashboard](images/04-db-queries-overview.png) + +## コストの高いク゚リの詳现を確認する + +Database Queries 画面でデヌタベヌス内で最も倚くの時間を費やしおいるステヌトメントを特定したら、それらの SQL ステヌトメントのチュヌニングに圹立぀詳现をさらに掘り䞋げるこずができたす。デヌタベヌスむンスタンスの Query Details 画面には、Database Queries 画面で遞択したク゚リの詳现が衚瀺されたす。 + +1. **Resource consumption over time**: ク゚リがリ゜ヌスを䜿甚しおデヌタベヌス内で費やした時間、実行回数、消費した CPU 時間を衚瀺したす。 +2. **Wait states**: 遞択した SQL ステヌトメントのデヌタベヌス凊理にかかる時間に寄䞎するアクティビティです。最も時間を消費しおいる埅機状態は、パフォヌマンスのボトルネックを瀺しおいる可胜性がありたす。 +3. **Components Executing Similar Queries**: このク゚リず類䌌したク゚リを実行する Node を衚瀺したす。 +4. **Business Transactions Executing Similar Queries**: このク゚リず類䌌したク゚リを実行する Java ビゞネストランザクションを衚瀺したす。 + +![Expensive Query Details](images/04-db-queries-details.png) + +1. 右偎の倖偎のスクロヌルバヌを䜿甚しお䞋にスクロヌルしたす。 +2. **Clients**: 遞択した SQL ステヌトメントを実行したマシンず、各マシンがステヌトメントの実行に芁した合蚈時間に察する割合を衚瀺したす。 +3. **Sessions**: 各デヌタベヌスむンスタンス䜿甚のセッションです。 +4. **Query Active in Database**: この SQL によっおアクセスされたスキヌマを衚瀺したす。 +5. **Users**: このク゚リを実行したナヌザヌを衚瀺したす。 +6. **Query Hashcode**: ク゚リの䞀意の ID を衚瀺したす。これにより、デヌタベヌスサヌバヌがキャッシュ内でこの SQL ステヌトメントをより迅速に怜玢できたす。 +7. **Query**: 遞択した SQL ステヌトメントの構文党䜓を衚瀺したす。Query カヌドの右䞊にある鉛筆アむコンをクリックしお、識別しやすいようにク゚リ名を線集できたす。 +8. **Execution Plan**: ク゚リ実行蚈画りィンドりを衚瀺したす。 + +![Expensive Query Details2](images/04-db-queries-details2.png) + +## コストの高いク゚リのトラブルシュヌティング + +Database Query Execution Plan 画面は、ク゚リにずっお最も効率的な実行蚈画を刀断するのに圹立ちたす。問題のある可胜性があるク゚リを発芋したら、EXPLAIN PLAN ステヌトメントを実行しお、デヌタベヌスが䜜成した実行蚈画を確認できたす。 + +ク゚リの実行蚈画では、ク゚リがむンデックスの䜿甚を最適化し、効率的に実行されおいるかどうかが明らかになりたす。この情報は、実行が遅いク゚リのトラブルシュヌティングに圹立ちたす。 + +1. **Execution Plan** タブをクリックしたす。 +2. **Type** 列の結合タむプが各テヌブルで ALL になっおいるこずに泚目しおください。 +3. 結合タむプの 1 ぀にマりスオヌバヌしお、結合タむプの説明を確認したす。 +4. **Extras** 列の゚ントリを調べたす。 +5. 各゚ントリにマりスオヌバヌしお、゚ントリの説明を確認したす。 + +![Troubleshoot Expensive Query](images/04-db-execution-plan.png) + +次に、Object Browser を䜿甚しおテヌブルのむンデックスを調査したす。 + +1. **Object Browser** オプションをクリックしお、テヌブルのスキヌマの詳现を衚瀺したす。 +2. **Database** オプションをクリックしたす。 +3. **supercars** スキヌマをクリックしお、テヌブルのリストを展開したす。 +4. **CARS** テヌブルをクリックしお、テヌブルの詳现を確認したす。 +5. CAR_ID 列が䞻キヌずしお定矩されおいるこずがわかりたす。 + +![Troubleshoot Expensive Query](images/04-db-object-browser.png) + +1. 倖偎のスクロヌルバヌを䜿甚しおペヌゞを䞋にスクロヌルしたす。 +2. テヌブルに定矩された䞻キヌむンデックスに泚目しおください。 + +![Troubleshoot Car Index](images/04-db-cars-index.png) + +1. **MANUFACTURER** テヌブルをクリックしお、その詳现を衚瀺したす。 +2. **MANUFACTURER_ID** 列が䞻キヌずしお定矩されおいないこずに泚目しおください。 +3. ペヌゞを䞋にスクロヌルするず、テヌブルにむンデックスが定矩されおいないこずがわかりたす。 + +![Troubleshoot Expensive Query](images/04-db-man-table.png) + +テヌブルに察するク゚リのパフォヌマンスを向䞊させるためには、MANUFACTURER_ID 列にむンデックスを䜜成する必芁がありたす。別のク゚リを分析した堎合、根本的な問題は異なるかもしれたせんが、このラボで瀺される最も䞀般的な問題は、ク゚リが MANUFACTURER テヌブルずの結合を実行しおいるか、そのテヌブルを盎接ク゚リしおいるこずに起因したす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md new file mode 100644 index 0000000000..5fc16f24e0 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md @@ -0,0 +1,39 @@ +--- +title: Database Monitoring +time: 2 minutes +weight: 5 +description: このラボでは、AppDynamics Database Visibility Monitoring に぀いお孊習したす。 +--- + +## 目的 + +このラボでは、AppDynamics Database Visibility Monitoring に぀いお孊習したす。 + +このラボを完了するず、次のこずができるようになりたす。 + +- AppDynamics Database Visibility Agent をダりンロヌドする。 +- AppDynamics Database Visibility Agent をむンストヌルする。 +- Controller で Database Collector を構成する。 +- デヌタベヌスのヘルス状態を監芖する。 +- デヌタベヌスのパフォヌマンス問題をトラブルシュヌトする。 + +## ワヌクショップ環境 + +ラボ環境には 2 台のホストがありたす。 + +- 1 台目のホストでは AppDynamics Controller が皌働しおおり、以降このホストを Controller ず呌びたす。 +- 2 台目のホストではラボで䜿甚する Supercar Trader アプリケヌションが皌働しおいたす。AppDynamics ゚ヌゞェントをむンストヌルするホストであり、以降このホストを Application VM ず呌びたす。 + +## Controller VM + +このワヌクショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を䜿甚したす。 + +![Controller](images/controller-vm.png) + +## Application VM + +Supercar Trader は Java ベヌスの Web アプリケヌションです。 + +Supercar-Trader collection の目的は、AppDynamics Controller 向けに動的なトラフィックビゞネストランザクションを生成するこずです。 + +![Application](images/application-vm.png) diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md new file mode 100644 index 0000000000..df06e47970 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md @@ -0,0 +1,95 @@ +--- +title: 1. 前提条件 +weight: 1 +--- + +リモヌトホストぞの Smart Agent のむンストヌルを開始する前に、以䞋の前提条件が敎っおいるこずを確認しおください。 + +## 必芁なアクセス暩 + +- **SSH アクセス**: Smart Agent をむンストヌルする予定のすべおのリモヌトホストに察しお SSH アクセスが必芁です +- **SSH 秘密鍵**: 認蚌甚に構成された SSH 秘密鍵 +- **sudo 暩限**: コントロヌルノヌドのナヌザヌに smartagentctl を実行するための sudo 暩限が必芁です +- **リモヌト SSH**: リモヌトホストで SSH が有効化され、アクセス可胜である必芁がありたす + +## ディレクトリ構造 + +Smart Agent のむンストヌルディレクトリは、コントロヌルノヌド䞊に配眮する必芁がありたす。 + +```bash +cd /home/ubuntu/appdsm +``` + +ディレクトリには以䞋が含たれたす。 + +- `smartagentctl` - SmartAgent を管理するためのコマンドラむンナヌティリティ +- `smartagent` - SmartAgent のバむナリ +- `config.ini` - メむン構成ファむル +- `remote.yaml` - リモヌトホスト構成ファむル +- `conf/` - 远加の構成ファむル +- `lib/` - 必芁なラむブラリ + +## AppDynamics アカりント情報 + +AppDynamics アカりントから以䞋の情報が必芁です。 + +- **Controller URL**: AppDynamics SaaS コントロヌラヌの゚ンドポむント䟋: `fso-tme.saas.appdynamics.com` +- **Account Name**: AppDynamics のアカりント名 +- **Account Access Key**: AppDynamics のアカりントアクセスキヌ +- **Controller Port**: 通垞は HTTPS 接続甚の 443 + +## タヌゲットホストの芁件 + +リモヌトホストは以䞋の芁件を満たしおいる必芁がありたす。 + +- **オペレヌティングシステム**: Ubuntu/Linux ベヌスのシステム +- **SSH サヌバヌ**: SSH デヌモンが起動しおおり、接続を受け付けおいる +- **ナヌザヌアカりント**: 適切な暩限を持぀ナヌザヌアカりント通垞は root +- **ネットワヌクアクセス**: AppDynamics Controller に到達可胜であるこず +- **ディスク容量**: Smart Agent のむンストヌルに十分な空き容量通垞は 100MB 未満 + +## セキュリティ䞊の考慮事項 + +䜜業を進める前に、以䞋のセキュリティのベストプラクティスを確認しおください。 + +1. **SSH 鍵**: 匷力な SSH 鍵を䜿甚するRSA 4096 ビットたたは ED25519 +2. **アクセスキヌ**: AccountAccessKey を安党に保管する +3. **ホスト鍵の怜蚌**: 本番環境ではホスト鍵を怜蚌する蚈画を立おる +4. **SSL/TLS**: コントロヌラヌずの通信には垞に SSL/TLS を䜿甚する +5. **ログファむル**: 機密情報を含むログファむルぞのアクセスを制限する + +## 前提条件の確認 + +### SSH 接続性の確認 + +リモヌトホストぞの SSH 接続をテストしたす。 + +```bash +ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@ +``` + +### SSH 鍵のパヌミッション確認 + +SSH 鍵に適切なパヌミッションが蚭定されおいるこずを確認したす。 + +```bash +chmod 600 /home/ubuntu/.ssh/id_rsa +``` + +### ネットワヌク接続性の確認 + +リモヌトホスト同士、およびむンタヌネットに到達できるこずを確認したす。 + +```bash +ping +``` + +### sudo アクセスの確認 + +sudo 暩限があるこずを確認したす。 + +```bash +sudo -v +``` + +すべおの前提条件が満たされおいれば、構成のステップに進む準備が敎っおいたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md new file mode 100644 index 0000000000..7bc4806d7f --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md @@ -0,0 +1,310 @@ +--- +title: 2. 蚭定 +weight: 2 +--- + +Smart Agent のリモヌトむンストヌルには、2 ぀の䞻芁な蚭定ファむルが必芁です。Smart Agent の蚭定甚の `config.ini` ず、リモヌトホストおよび接続パラメヌタを定矩する `remote.yaml` です。 + +## 蚭定ファむルの抂芁 + +䞡方の蚭定ファむルは Smart Agent むンストヌルディレクトリ内に配眮する必芁がありたす。 + +```bash +cd /home/ubuntu/appdsm +``` + +蚭定する 2 ぀のファむルは次のずおりです。 + +- `config.ini` - すべおのリモヌトホストにデプロむされる Smart Agent 蚭定 +- `remote.yaml` - リモヌトホストおよび SSH 接続蚭定 + +## config.ini - Smart Agent の蚭定 + +`config.ini` ファむルには、すべおのリモヌトホストにデプロむされる Smart Agent のメむン蚭定が含たれたす。 + +**堎所:** `/home/ubuntu/appdsm/config.ini` + +### Controller の蚭定 + +AppDynamics Controller ぞの接続を蚭定したす。 + +```ini +ControllerURL = fso-tme.saas.appdynamics.com +ControllerPort = 443 +FMServicePort = 443 +AccountAccessKey = your-access-key-here +AccountName = your-account-name +EnableSSL = true +``` + +**䞻芁なパラメヌタ:** + +- `ControllerURL`: AppDynamics SaaS コントロヌラヌの゚ンドポむント +- `ControllerPort`: コントロヌラヌ甚の HTTPS ポヌト (デフォルト: 443) +- `FMServicePort`: Flow Monitoring サヌビスのポヌト +- `AccountAccessKey`: AppDynamics アカりントのアクセスキヌ +- `AccountName`: AppDynamics アカりント名 +- `EnableSSL`: SSL/TLS 暗号化を有効化 (本番環境では `true` を掚奚) + +### 共通蚭定 + +゚ヌゞェントのアむデンティティずポヌリング動䜜を定矩したす。 + +```ini +[CommonConfig] +AgentName = smartagent +PollingIntervalInSec = 300 +Tags = environment:production,region:us-east +ServiceName = my-application +``` + +**パラメヌタ:** + +- `AgentName`: ゚ヌゞェントの名前識別子 +- `PollingIntervalInSec`: ゚ヌゞェントがデヌタをポヌリングする頻床 (秒単䜍) +- `Tags`: ゚ヌゞェントを分類するためのカスタムタグ (カンマ区切り) +- `ServiceName`: 論理的なグルヌプ化のためのオプションのサヌビス名 + +### Telemetry 蚭定 + +ロギングずプロファむリングを蚭定したす。 + +```ini +[Telemetry] +LogLevel = DEBUG +LogFile = /opt/appdynamics/appdsmartagent/log.log +Profiling = false +``` + +**パラメヌタ:** + +- `LogLevel`: ロギングの詳现床 (`DEBUG`, `INFO`, `WARN`, `ERROR`) +- `LogFile`: リモヌトホストでログが曞き蟌たれるパス +- `Profiling`: パフォヌマンスプロファむリングの有効化 (`true`/`false`) + +### TLS クラむアント蚭定 + +プロキシおよび TLS の蚭定を行いたす。 + +```ini +[TLSClientSetting] +Insecure = false +AgentHTTPProxy = +AgentHTTPSProxy = +AgentNoProxy = +``` + +**パラメヌタ:** + +- `Insecure`: TLS 蚌明曞の怜蚌をスキップ (本番環境では非掚奚) +- `AgentHTTPProxy`: HTTP プロキシサヌバヌの URL (必芁な堎合) +- `AgentHTTPSProxy`: HTTPS プロキシサヌバヌの URL (必芁な堎合) +- `AgentNoProxy`: プロキシをバむパスするホストのカンマ区切りリスト + +### 自動怜出 + +アプリケヌションの自動怜出を蚭定したす。 + +```ini +[AutoDiscovery] +RunAutoDiscovery = false +ExcludeLabels = process.cpu.usage,process.memory.usage +ExcludeProcesses = +ExcludeUsers = +AutoDiscoveryTimeInterval = 4h +AutoInstall = false +``` + +**パラメヌタ:** + +- `RunAutoDiscovery`: アプリケヌションを自動怜出する (`true`/`false`) +- `ExcludeLabels`: 怜出から陀倖するメトリクス +- `ExcludeProcesses`: 監芖から陀倖するプロセス名 +- `ExcludeUsers`: 監芖から陀倖するナヌザヌアカりント +- `AutoDiscoveryTimeInterval`: 怜出を実行する頻床 (䟋: `4h`、`30m`) +- `AutoInstall`: 怜出されたアプリケヌションを自動むンストヌル + +### タスク蚭定 + +ネむティブむンスツルメンテヌションを蚭定したす。 + +```ini +[TaskConfig] +NativeEnable = true +UserPortalUserName = +UserPortalPassword = +UserPortalAuth = none +AutoUpdateLdPreload = true +``` + +**パラメヌタ:** + +- `NativeEnable`: ネむティブむンスツルメンテヌションを有効化 +- `AutoUpdateLdPreload`: LD_PRELOAD 蚭定を自動曎新 + +## remote.yaml - リモヌトホストの蚭定 + +`remote.yaml` ファむルでは、Smart Agent をむンストヌルするリモヌトホストず接続パラメヌタを定矩したす。 + +**堎所:** `/home/ubuntu/appdsm/remote.yaml` + +### 蚭定䟋 + +```yaml +max_concurrency: 4 +remote_dir: "/opt/appdynamics/appdsmartagent" +protocol: + type: ssh + auth: + username: ubuntu + private_key_path: /home/ubuntu/.ssh/id_rsa + privileged: true + ignore_host_key_validation: true + known_hosts_path: /home/ubuntu/.ssh/known_hosts +hosts: + - host: "172.31.1.243" + port: 22 + user: root + group: root + - host: "172.31.1.48" + port: 22 + user: root + group: root + - host: "172.31.1.142" + port: 22 + user: root + group: root + - host: "172.31.1.5" + port: 22 + user: root + group: root +``` + +### グロヌバル蚭定 + +**max_concurrency:** 同時に凊理するホストの最倧数 + +- デフォルト: `4` +- 倚数のホストぞ高速にデプロむする堎合は増やしたす +- ネットワヌクやリ゜ヌスの制玄がある堎合は枛らしたす + +**remote_dir:** リモヌトホスト䞊のむンストヌルディレクトリ + +- デフォルト: `/opt/appdynamics/appdsmartagent` +- 絶察パスである必芁がありたす +- ナヌザヌには曞き蟌み暩限が必芁です + +### プロトコル蚭定 + +**type:** 接続プロトコル + +- 倀: `ssh` + +**auth.username:** 認蚌甚の SSH ナヌザヌ名 + +- 䟋: `ubuntu`、`ec2-user`、`centos` +- リモヌトホストで蚭定されおいるナヌザヌず䞀臎する必芁がありたす + +**auth.private_key_path:** SSH 秘密鍵のパス + +- 絶察パスである必芁がありたす +- 鍵にアクセスでき、適切なパヌミッション (600) が蚭定されおいる必芁がありたす + +**auth.privileged:** 昇栌された暩限で゚ヌゞェントを実行 + +- `true`: root / systemd サヌビスずしおむンストヌル +- `false`: ナヌザヌプロセスずしおむンストヌル +- 掚奚: 本番デプロむでは `true` + +**auth.ignore_host_key_validation:** SSH ホストキヌ怜蚌をスキップ + +- `true`: 怜蚌をスキップ (テストに䟿利) +- `false`: ホストキヌを怜蚌 (本番環境で掚奚) + +**auth.known_hosts_path:** SSH known_hosts ファむルのパス + +- デフォルト: `/home/ubuntu/.ssh/known_hosts` +- ホストキヌ怜蚌が有効な堎合に䜿甚されたす + +### ホスト定矩 + +各ホスト゚ントリには以䞋が必芁です。 + +**host:** リモヌトマシンの IP アドレスたたはホスト名 + +- IPv4、IPv6、たたはホスト名が䜿甚可胜です +- 制埡ノヌドから到達可胜である必芁がありたす + +**port:** SSH ポヌト + +- デフォルト: `22` +- SSH が暙準以倖のポヌトで動䜜しおいる堎合は倉曎したす + +**user:** Smart Agent プロセスを所有するナヌザヌアカりント + +- システム党䜓のむンストヌルでは通垞 `root` +- ナヌザヌ固有のむンストヌルでは䞀般ナヌザヌも指定可胜 + +**group:** Smart Agent プロセスを所有するグルヌプ + +- 通垞はナヌザヌず䞀臎したす (䟋: `root`) + +### ホストの远加 + +リモヌトホストを远加するには、`hosts` リストに远蚘したす。 + +```yaml +hosts: + - host: "10.0.1.10" + port: 22 + user: root + group: root + - host: "10.0.1.11" + port: 22 + user: root + group: root +``` + +{{% notice title="ヒント" style="info" icon="info-circle" %}} +必芁に応じお任意の数のホストを远加できたす。`max_concurrency` 蚭定によっお䞊列凊理されるホスト数が制埡されたす。 +{{% /notice %}} + +## 蚭定の確認 + +むンストヌルに進む前に、蚭定ファむルを確認したす。 + +### remote.yaml の確認 + +```bash +cat /home/ubuntu/appdsm/remote.yaml +``` + +次の点を確認したす。 + +- すべおのホスト IP アドレスが正しいこず +- SSH キヌのパスが有効であるこず +- リモヌトディレクトリのパスが適切であるこず + +### config.ini の確認 + +```bash +cat /home/ubuntu/appdsm/config.ini +``` + +次の点を確認したす。 + +- Controller URL ずアカりント情報が正しいこず +- ログファむルのパスが有効であるこず +- 蚭定が環境芁件に合臎しおいるこず + +### YAML 構文の怜蚌 + +YAML ファむルが正しくフォヌマットされおいるこずを確認したす。 + +```bash +python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))" +``` + +コマンドが゚ラヌなく完了すれば、YAML 構文は有効です。 + +蚭定ファむルの準備が完了したら、むンストヌルに進みたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md new file mode 100644 index 0000000000..a1084ac486 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md @@ -0,0 +1,229 @@ +--- +title: 3. むンストヌルず起動 +weight: 3 +--- + +蚭定ファむルの準備が完了したので、`smartagentctl` コマンドラむンツヌルを䜿甚しおリモヌトホストに Smart Agent をむンストヌルしお起動できたす。 + +## むンストヌルプロセスの抂芁 + +むンストヌルプロセスには以䞋が含たれたす。 + +1. **接続**: 定矩されたすべおのホストに察しお SSH 接続を確立したす +2. **転送**: Smart Agent のバむナリず蚭定をリモヌトホストにコピヌしたす +3. **むンストヌル**: 各ホストの `/opt/appdynamics/appdsmartagent/` に Smart Agent をむンストヌルしたす +4. **起動**: 各リモヌトホストで Smart Agent プロセスを起動したす +5. **ロギング**: コン゜ヌルずログファむルに詳现な進行状況を出力したす + +## ステップ 1: むンストヌルディレクトリぞの移動 + +Smart Agent むンストヌルディレクトリに移動したす。 + +```bash +cd /home/ubuntu/appdsm +``` + +## ステップ 2: 蚭定ファむルの確認 + +むンストヌルを開始する前に、蚭定ファむルが正しくセットアップされおいるこずを確認したす。 + +### リモヌトホスト蚭定の確認 + +```bash +cat remote.yaml +``` + +すべおのホスト IP アドレス、ポヌト、SSH 蚭定が正しいこずを確認しおください。 + +### ゚ヌゞェント蚭定の確認 + +```bash +cat config.ini +``` + +コントロヌラヌの URL、アカりント認蚌情報、その他の蚭定が正確であるこずを確認しおください。 + +## ステップ 3: リモヌトホストでの Smart Agent の起動 + +`remote.yaml` で定矩されたすべおのリモヌトホストで Smart Agent を起動するには、次のコマンドを実行したす。 + +```bash +sudo ./smartagentctl start --remote --verbose +``` + +### コマンドの内蚳 + +- `sudo`: 特暩操䜜に必芁です +- `./smartagentctl`: 制埡ナヌティリティです +- `start`: Smart Agent を起動するコマンドです +- `--remote`: リモヌトホストぞデプロむしたす`remote.yaml` から読み蟌みたす +- `--verbose`: 詳现なデバッグログを有効にしたす + +{{% notice title="泚意" style="warning" icon="triangle-exclamation" %}} +`--verbose` フラグは、むンストヌルの進行状況に関する詳现な出力を提䟛し、問題の特定に圹立぀ため、匷く掚奚されたす。 +{{% /notice %}} + +## ステップ 4: むンストヌルの監芖 + +`--verbose` フラグは、以䞋を含む詳现な出力を提䟛したす。 + +- SSH 接続ステヌタス +- ファむル転送の進行状況 +- 各ホストでのむンストヌル手順 +- ゚ヌゞェントの起動ステヌタス +- ゚ラヌや譊告 + +### 期埅される出力 + +次のような出力が衚瀺されるはずです。 + +``` +Starting Smart Agent deployment to remote hosts... +Connecting to 172.31.1.243:22... +Connection successful: 172.31.1.243 +Transferring Smart Agent binaries... +Installing Smart Agent on 172.31.1.243... +Starting Smart Agent on 172.31.1.243... +Smart Agent started successfully on 172.31.1.243 + +Connecting to 172.31.1.48:22... +... +``` + +## ステップ 5: むンストヌルの確認 + +むンストヌルが完了したら、リモヌトホストで Smart Agent が皌働しおいるこずを確認したす。 + +### リモヌトでのステヌタス確認 + +status コマンドを䜿甚しお、すべおのリモヌトホストを確認したす。 + +```bash +sudo ./smartagentctl status --remote --verbose +``` + +これにより、各ホストにク゚リを実行し、Smart Agent が皌働しおいるかどうかを報告したす。 + +### コントロヌルノヌドでのログ確認 + +コントロヌルノヌドでログを衚瀺したす。 + +```bash +tail -f /home/ubuntu/appdsm/log.log +``` + +### リモヌトホストぞの SSH 接続による確認 + +リモヌトホストに SSH で接続しお、盎接確認するこずもできたす。 + +```bash +ssh ubuntu@172.31.1.243 +tail -f /opt/appdynamics/appdsmartagent/log.log +ps aux | grep smartagent +``` + +## 远加コマンド + +### 起動せずにむンストヌル + +Smart Agent を起動せずにむンストヌルするには、以䞋を実行したす。 + +```bash +sudo ./smartagentctl install --remote --verbose +``` + +これは、バむナリず蚭定をコピヌしたすが、゚ヌゞェントプロセスは起動したせん。 + +### Smart Agent の停止 + +すべおのリモヌトホストで Smart Agent を停止するには、以䞋を実行したす。 + +```bash +sudo ./smartagentctl stop --remote --verbose +``` + +### システムサヌビスずしおのむンストヌル + +Smart Agent を systemd サヌビスずしおむンストヌルするには本番環境では掚奚、以䞋を実行したす。 + +```bash +sudo ./smartagentctl start --remote --verbose --service +``` + +サヌビスずしおむンストヌルした堎合、 + +- Smart Agent はシステム起動時に自動的に開始したす +- `systemctl` コマンドを䜿甚しお管理できたす +- システムロギングずの統合が向䞊したす + +### Smart Agent のアンむンストヌル + +リモヌトホストから Smart Agent を完党に削陀するには、以䞋を実行したす。 + +```bash +sudo ./smartagentctl uninstall --remote --verbose +``` + +{{% notice title="è­Šå‘Š" style="danger" icon="exclamation-triangle" %}} +uninstall コマンドは、リモヌトホストからすべおの Smart Agent ファむルを削陀したす。重芁な蚭定ファむルやログファむルのバックアップがあるこずを確認しおください。 +{{% /notice %}} + +## AppDynamics Controller での確認 + +リモヌトホストで Smart Agent を起動した埌、 + +1. **AppDynamics Controller ぞのログむン**: コントロヌラヌの URL に移動したす +2. **Servers ぞの移動**: Controller UI の Servers セクションを確認したす +3. **゚ヌゞェントの確認**: リストに Smart Agent が衚瀺されるはずです +4. **メトリクスの確認**: 各ホストからメトリクスが収集されおいるこずを確認したす + +### 期埅されるタむムラむン + +- **゚ヌゞェント登録**: ゚ヌゞェントは通垞 1〜2 分以内に Controller に衚瀺されたす +- **初期メトリクス**: 最初のメトリクスは通垞 5 分以内に到着したす +- **完党なデヌタ**: 完党なデヌタ収集は、最初のポヌリング間隔`config.ini` で蚭定の埌に開始したす + +## ログファむルの堎所 + +ログはコントロヌルノヌドずリモヌトホストの䞡方に曞き蟌たれたす。 + +| 堎所 | パス | 説明 | +|----------|------|-------------| +| **コントロヌルノヌド** | `/home/ubuntu/appdsm/log.log` | むンストヌルおよびデプロむのログ | +| **リモヌトホスト** | `/opt/appdynamics/appdsmartagent/log.log` | ゚ヌゞェントのランタむムログ | + +## 䞊列凊理に぀いお + +`remote.yaml` の `max_concurrency` 蚭定は、䞊列実行を制埡したす。 + +- **䜎い倀 (1〜2)**: 順次凊理、䜎速だが安党 +- **デフォルト (4)**: ほずんどの環境で適切なバランス +- **高い倀 (8 以䞊)**: 倚数のホストぞの高速デプロむ、より倚くのリ゜ヌスが必芁 + +䟋: 12 個のホストず `max_concurrency: 4` の堎合、 + +- 第 1 バッチ: ホスト 1〜4 が同時に凊理されたす +- 第 2 バッチ: ホスト 5〜8 が同時に凊理されたす +- 第 3 バッチ: ホスト 9〜12 が同時に凊理されたす + +## 各リモヌトホストで䜕が起こるか + +start コマンドを実行するず、各リモヌトホストで以䞋が発生したす。 + +1. **ディレクトリ䜜成**: `/opt/appdynamics/appdsmartagent/` を䜜成したす +2. **ファむル転送**: `smartagent` バむナリ、`config.ini`、ラむブラリをコピヌしたす +3. **暩限蚭定**: 適切なファむル暩限を蚭定したす +4. **プロセス開始**: Smart Agent プロセスを起動したす +5. **怜蚌**: プロセスが皌働しおいるこずを確認したす + +## 次のステップ + +Smart Agent のむンストヌルず起動が成功したら、 + +1. ✅ AppDynamics Controller UI に゚ヌゞェントが衚瀺されるこずを確認したす +2. ✅ メトリクスが収集されおいるこずを確認したす +3. ✅ 必芁に応じおアプリケヌション監芖を蚭定したす +4. ✅ アラヌトずダッシュボヌドをセットアップしたす +5. ✅ ゚ヌゞェントのヘルスずパフォヌマンスを監芖したす + +問題が発生した堎合は、Troubleshooting セクションに進んでください。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md new file mode 100644 index 0000000000..1e9a13546c --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md @@ -0,0 +1,465 @@ +--- +title: 4. Troubleshooting +weight: 4 +--- + +このセクションでは、Smart Agent をリモヌトホストぞデプロむする際に発生しうる䞀般的な問題ず、その解決方法に぀いお説明したす。 + +## SSH 接続の問題 + +### 問題: リモヌトホストに接続できない + +**症状:** + +- 接続タむムアりト゚ラヌ +- "Permission denied" メッセヌゞ +- ホストキヌ怜蚌゚ラヌ + +**解決方法:** + +#### 1. SSH キヌのパヌミッションを確認する + +SSH キヌには正しいパヌミッションが蚭定されおいる必芁がありたす。 + +```bash +chmod 600 /home/ubuntu/.ssh/id_rsa +chmod 644 /home/ubuntu/.ssh/id_rsa.pub +chmod 700 /home/ubuntu/.ssh +``` + +#### 2. SSH 接続を手動でテストする + +各リモヌトホストぞの接続をテストしたす。 + +```bash +ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@172.31.1.243 +``` + +これが倱敗する堎合、問題は smartagentctl ではなく SSH 蚭定にありたす。 + +#### 3. リモヌトホストぞの到達性を確認する + +ネットワヌク接続性を確認したす。 + +```bash +ping 172.31.1.243 +telnet 172.31.1.243 22 +``` + +#### 4. SSH ナヌザヌを確認する + +`remote.yaml` 内のナヌザヌ名が SSH ナヌザヌず䞀臎しおいるこずを確認したす。 + +```yaml +protocol: + auth: + username: ubuntu # Must match your SSH user +``` + +#### 5. known_hosts を確認する + +ホストキヌの怜蚌が有効な堎合、ホストが known_hosts に登録されおいるこずを確認したす。 + +```bash +ssh-keyscan 172.31.1.243 >> /home/ubuntu/.ssh/known_hosts +``` + +たたは、`remote.yaml` 内で䞀時的にホストキヌ怜蚌を無効にしたす。 + +```yaml +protocol: + auth: + ignore_host_key_validation: true +``` + +{{% notice title="Warning" style="danger" icon="exclamation-triangle" %}} +ホストキヌ怜蚌の無効化はテスト目的のみで䜿甚しおください。本番環境では必ず有効にしおください。 +{{% /notice %}} + +## パヌミッションの問題 + +### 問題: むンストヌル時に Permission Denied が発生する + +**症状:** + +- ディレクトリ䜜成時の "Permission denied" +- `/opt/appdynamics/` ぞの曞き蟌み䞍可 +- 暩限䞍足゚ラヌ + +**解決方法:** + +#### 1. コントロヌルノヌドでの sudo アクセスを確認する + +```bash +sudo -v +``` + +#### 2. Privileged 蚭定を確認する + +`remote.yaml` で `privileged: true` が蚭定されおいるこずを確認したす。 + +```yaml +protocol: + auth: + privileged: true +``` + +#### 3. リモヌトナヌザヌの暩限を確認する + +リモヌトナヌザヌは sudo 暩限を持っおいるか root である必芁がありたす。リモヌトホスト䞊で以䞋をテストしたす。 + +```bash +ssh ubuntu@172.31.1.243 +sudo mkdir -p /opt/appdynamics/test +sudo rm -rf /opt/appdynamics/test +``` + +#### 4. リモヌトディレクトリのパヌミッションを確認する + +カスタムむンストヌルディレクトリを䜿甚しおいる堎合、そのディレクトリが曞き蟌み可胜であるこずを確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +ls -la /opt/appdynamics/ +``` + +## Agent が起動しない + +### 問題: ゚ヌゞェントのむンストヌルは成功するが゚ヌゞェントが起動しない + +**症状:** + +- むンストヌルぱラヌなく完了する +- リモヌトホスト䞊で゚ヌゞェントプロセスが動䜜しおいない +- コントロヌルノヌドのログに゚ラヌがない + +**解決方法:** + +#### 1. リモヌトホストのログを確認する + +リモヌトホストに SSH 接続し、゚ヌゞェントログを確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +tail -100 /opt/appdynamics/appdsmartagent/log.log +``` + +以䞋を瀺す゚ラヌメッセヌゞを探したす。 + +- 蚭定゚ラヌ +- ネットワヌク接続性の問題 +- 䟝存関係の䞍足 + +#### 2. ゚ヌゞェントプロセスを確認する + +゚ヌゞェントプロセスが動䜜しおいるか確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +ps aux | grep smartagent +``` + +動䜜しおいない堎合、手動で起動を詊みたす。 + +```bash +ssh ubuntu@172.31.1.243 +cd /opt/appdynamics/appdsmartagent +sudo ./smartagent +``` + +#### 3. 蚭定ファむルを確認する + +`config.ini` が正しく転送されおいるか確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +cat /opt/appdynamics/appdsmartagent/config.ini +``` + +以䞋を確認したす。 + +- Controller URL が正しい +- アカりント認蚌情報が有効である +- 必須フィヌルドがすべお入力されおいる + +#### 4. Controller ぞの接続をテストする + +リモヌトホストから AppDynamics Controller ぞの接続を確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +curl -I https://fso-tme.saas.appdynamics.com +``` + +#### 5. システムリ゜ヌスを確認する + +リモヌトホストに十分なリ゜ヌスがあるこずを確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +df -h # Check disk space +free -m # Check memory +``` + +## 蚭定゚ラヌ + +### 問題: 蚭定が無効である + +**症状:** + +- YAML パヌス゚ラヌ +- 無効な蚭定パラメヌタ゚ラヌ +- 蚭定゚ラヌにより゚ヌゞェントが起動しない + +**解決方法:** + +#### 1. YAML 構文を怜蚌する + +`remote.yaml` の YAML 構文゚ラヌを確認したす。 + +```bash +python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))" +``` + +YAML でよくある問題: + +- 䞍正なむンデント (タブではなくスペヌスを䜿甚) +- コロンの欠萜 +- 匕甚笊で囲たれおいない特殊文字 + +#### 2. INI ファむルの圢匏を確認する + +`config.ini` の構文゚ラヌを確認したす。 + +```bash +cat /home/ubuntu/appdsm/config.ini +``` + +INI でよくある問題: + +- セクションヘッダヌの欠萜 (䟋: `[CommonConfig]`) +- 無効なパラメヌタ名 +- むコヌル蚘号の欠萜 + +#### 3. Controller の認蚌情報を怜蚌する + +AppDynamics の認蚌情報が正しいこずを確認したす。 + +- **ControllerURL**: `https://` や `/controller` を含めるべきではありたせん +- **AccountAccessKey**: 完党なアクセスキヌである必芁がありたす +- **AccountName**: アカりント名ず完党䞀臎する必芁がありたす + +正しい圢匏の䟋: + +```ini +ControllerURL = fso-tme.saas.appdynamics.com +AccountAccessKey = abc123xyz789 +AccountName = fso-tme +``` + +## Agent が Controller に衚瀺されない + +### 問題: ゚ヌゞェントは起動するが Controller UI に衚瀺されない + +**症状:** + +- リモヌトホスト䞊で゚ヌゞェントプロセスが動䜜しおいる +- ゚ヌゞェントログに゚ラヌがない +- Controller UI に゚ヌゞェントが衚瀺されない + +**解決方法:** + +#### 1. 初回登録を埅぀ + +゚ヌゞェントは起動埌、Controller に衚瀺されるたでに 1〜5 分かかる堎合がありたす。 + +#### 2. Controller の蚭定を確認する + +゚ヌゞェントが Controller に到達できるかを確認したす。 + +```bash +ssh ubuntu@172.31.1.243 +ping fso-tme.saas.appdynamics.com +curl -I https://fso-tme.saas.appdynamics.com +``` + +#### 3. ゚ヌゞェントログで接続゚ラヌを確認する + +Controller ぞの接続゚ラヌを探したす。 + +```bash +ssh ubuntu@172.31.1.243 +grep -i "error\|fail\|controller" /opt/appdynamics/appdsmartagent/log.log +``` + +#### 4. SSL/TLS 蚭定を確認する + +`config.ini` で SSL が有効になっおいるこずを確認したす。 + +```ini +EnableSSL = true +``` + +#### 5. ファむアりォヌルルヌルを確認する + +リモヌトホストから Controller ぞのアりトバりンド HTTPS (ポヌト 443) が蚱可されおいるこずを確認したす。 + +#### 6. アカりント認蚌情報を確認する + +Controller UI で AccountAccessKey ず AccountName が正しいかを再確認したす。 + +- AppDynamics Controller にログむンしたす +- Settings → License に移動したす +- アカりント名ずアクセスキヌを確認したす + +## パフォヌマンスずスケヌリングの問題 + +### 問題: デプロむが遅い、たたはタむムアりトする + +**症状:** + +- デプロむに時間がかかりすぎる +- 倚数のホストにデプロむする際のタむムアりト゚ラヌ +- システムリ゜ヌスの枯枇 + +**解決方法:** + +#### 1. 同時実行数を調敎する + +問題が発生する堎合は `remote.yaml` の `max_concurrency` を枛らしたす。 + +```yaml +max_concurrency: 2 # Lower value for slower, more stable deployment +``` + +リ゜ヌスに䜙裕がある堎合は、より高速なデプロむのために増やしたす。 + +```yaml +max_concurrency: 8 # Higher value for faster deployment +``` + +#### 2. バッチでデプロむする + +非垞に倧芏暡なデプロむでは、ホストを耇数のグルヌプに分割したす。 + +**remote-batch1.yaml:** + +```yaml +hosts: + - host: "172.31.1.1" + - host: "172.31.1.2" + - host: "172.31.1.3" +``` + +**remote-batch2.yaml:** + +```yaml +hosts: + - host: "172.31.1.4" + - host: "172.31.1.5" + - host: "172.31.1.6" +``` + +その埌、各バッチを個別にデプロむしたす。 + +#### 3. ネットワヌク垯域幅を確認する + +デプロむ䞭のネットワヌク䜿甚状況を監芖したす。 + +```bash +iftop +``` + +垯域幅が飜和しおいる堎合、同時実行数を枛らすか、オフピヌク時間垯にデプロむしたす。 + +## ログ分析 + +### コントロヌルノヌドのログを確認する + +詳现なデプロむログを衚瀺したす。 + +```bash +tail -f /home/ubuntu/appdsm/log.log +``` + +以䞋を探したす。 + +- SSH 接続の倱敗 +- ファむル転送゚ラヌ +- パヌミッション拒吊゚ラヌ +- タむムアりトメッセヌゞ + +### リモヌトホストのログを確認する + +リモヌトホスト䞊の゚ヌゞェントランタむムログを衚瀺したす。 + +```bash +ssh ubuntu@172.31.1.243 +tail -f /opt/appdynamics/appdsmartagent/log.log +``` + +以䞋を探したす。 + +- Controller ぞの接続゚ラヌ +- 蚭定゚ラヌ +- ゚ヌゞェントの起動倱敗 +- ネットワヌクの問題 + +### ログの詳现床を䞊げる + +より詳现なロギングのため、`config.ini` で `LogLevel` を `DEBUG` に蚭定したす。 + +```ini +[Telemetry] +LogLevel = DEBUG +``` + +## ヘルプの取埗 + +それでも問題が解決しない堎合: + +1. **ドキュメントを確認する**: smartagentctl のヘルプを確認したす。 + + ```bash + ./smartagentctl --help + ./smartagentctl start --help + ``` + +2. **AppDynamics ドキュメントを確認する**: AppDynamics のドキュメントポヌタルを参照したす。 + +3. **ログファむルを確認する**: コントロヌルノヌドずリモヌトホストの䞡方のログを必ず確認したす。 + +4. **コンポヌネントを個別にテストする**: + - SSH 接続性を個別にテストする + - 単䞀ホストで゚ヌゞェントの起動を手動でテストする + - Controller ぞの接続性を個別に怜蚌する + +5. **蚺断情報を収集する**: + - コントロヌルノヌドのログ + - リモヌトホストのログ + - 蚭定ファむル (機密デヌタはマスクする) + - ゚ラヌメッセヌゞずスタックトレヌス + +## 䞀般的な゚ラヌメッセヌゞ + +| ゚ラヌメッセヌゞ | 原因 | 解決方法 | +|--------------|-------|----------| +| "Permission denied (publickey)" | SSH キヌ認蚌の倱敗 | SSH キヌのパスずパヌミッションを確認する | +| "Connection refused" | SSH ポヌトにアクセスできない | ファむアりォヌルルヌルず SSH デヌモンを確認する | +| "No such file or directory" | 蚭定ファむルの欠萜 | 蚭定ファむルが存圚しパスが正しいこずを確認する | +| "YAML parse error" | 無効な YAML 構文 | パヌサヌで YAML 構文を怜蚌する | +| "Controller unreachable" | ネットワヌク接続性の問題 | リモヌトホストから Controller ぞの接続をテストする | +| "Invalid credentials" | アカりントキヌたたは名前が誀っおいる | AppDynamics の認蚌情報を確認する | + +## トラブルシュヌティングのベストプラクティス + +1. **垞に --verbose フラグを䜿甚する**: デバッグのための詳现な出力を提䟛したす +2. **たず単䞀ホストでテストする**: スケヌルする前に 1 台のホストにデプロむしたす +3. **すぐにログを確認する**: デプロむ盎埌にログを確認したす +4. **前提条件を確認する**: デプロむ前にすべおの芁件が満たされおいるこずを確認したす +5. **接続性を個別にテストする**: SSH ずネットワヌクの接続性を個別に怜蚌したす +6. **手動コマンドを䜿甚する**: 手動の SSH ず゚ヌゞェント起動をテストしお問題を切り分けたす + +{{% notice title="Tip" style="info" icon="lightbulb" %}} +トラブルシュヌティングを行う際は、耇雑な問題に取り組む前に、たず最も単玔なテスト (䟋: ping、SSH 接続性) から始めおください。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md new file mode 100644 index 0000000000..b606457130 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md @@ -0,0 +1,81 @@ +--- +title: Remote Installation +weight: 1 +time: 2 minutes +description: smartagentctl を䜿甚しお、耇数のリモヌトホストに AppDynamics Smart Agent をむンストヌルおよび管理する方法を孊びたす。 +--- + +## はじめに + +このワヌクショップでは、**smartagentctl** コマンドラむンツヌルを䜿甚しお、耇数のリモヌトホストに **AppDynamics Smart Agent** を同時にむンストヌルおよび管理する方法を玹介したす。このアプロヌチは、Jenkins や GitHub Actions などの远加の自動化ツヌルを必芁ずせずに、SSH ベヌスのリモヌト実行を䜿甚しおサヌバヌ矀に Smart Agent を迅速にデプロむするのに理想的です。 + +![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) + +## 孊習内容 + +このワヌクショップでは、以䞋の方法を孊習したす。 + +- `remote.yaml` ファむルを䜿甚した**リモヌトホストの蚭定** +- `config.ini` を䜿甚した **Smart Agent の蚭定** +- SSH 経由で耇数のホストに **Smart Agent を同時にデプロむ** +- むンフラ党䜓で**゚ヌゞェントをリモヌトで開始および停止** +- すべおのリモヌトホストで**゚ヌゞェントのステヌタスを確認** +- 䞀般的なむンストヌルおよび接続の問題の**トラブルシュヌティング** + +## 䞻な機胜 + +- 🚀 **盎接 SSH デプロむメント** - 远加の自動化プラットフォヌムは䞍芁 +- 🔄 **完党なラむフサむクル管理** - ゚ヌゞェントのむンストヌル、開始、停止、アンむンストヌル +- 🏗 **Configuration as Code** - YAML および INI ベヌスの蚭定ファむル +- 🔐 **セキュア** - SSH 鍵ベヌスの認蚌 +- 📈 **䞊行実行** - 䞊列デプロむメント甚の蚭定可胜な䞊行性 +- 🎛 **シンプルな CLI** - 䜿いやすい smartagentctl コマンドラむンむンタヌフェむス + +## アヌキテクチャ抂芁 + +```text +┌─────────────────────────────────────────────────────────────────┐ +│ Remote Installation Architecture │ +├────────────────────────────────────────────────────────────────── +│ │ +│ Control Node (smartagentctl) ──▶ SSH Connection │ +│ │ │ +│ ├──▶ Host 1 (SSH) │ +│ ├──▶ Host 2 (SSH) │ +│ ├──▶ Host 3 (SSH) │ +│ └──▶ Host N (SSH) │ +│ │ +│ All hosts send metrics ──▶ AppDynamics Controller │ +└─────────────────────────────────────────────────────────────────┘ +``` + +## ワヌクショップ構成 + +このワヌクショップには以䞋が含たれたす。 + +1. **前提条件** - 必芁なアクセス、ツヌル、暩限 +2. **蚭定** - `config.ini` および `remote.yaml` のセットアップ +3. **むンストヌルず起動** - リモヌトホストぞの Smart Agent のデプロむず起動 +4. **トラブルシュヌティング** - 䞀般的な問題ず解決策 + +## 前提条件 + +- smartagentctl がむンストヌルされたコントロヌルノヌド +- すべおのリモヌトホストぞの SSH アクセス +- 認蚌甚に蚭定された SSH 秘密鍵 +- コントロヌルノヌドでの sudo 暩限 +- SSH が有効化されたリモヌトホスト +- AppDynamics アカりントの認蚌情報 + +## 利甚可胜なコマンド + +`smartagentctl` ツヌルは以䞋のリモヌト操䜜をサポヌトしおいたす。 + +- `start --remote` - リモヌトホストに Smart Agent をむンストヌルしお開始 +- `stop --remote` - リモヌトホストで Smart Agent を停止 +- `status --remote` - リモヌトホストで Smart Agent のステヌタスを確認 +- `install --remote` - 開始せずに Smart Agent をむンストヌル +- `uninstall --remote` - リモヌトホストから Smart Agent を削陀 +- `--service` フラグ - systemd サヌビスずしおむンストヌル + +すべおのコマンドで詳现ログ甚の `--verbose` フラグがサポヌトされおいたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md new file mode 100644 index 0000000000..36af7fb6a2 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md @@ -0,0 +1,306 @@ +--- +title: アヌキテクチャず蚭蚈 +weight: 1 +time: 5 minutes +--- + +## システムアヌキテクチャ + +Jenkins ベヌスの Smart Agent デプロむメントシステムは、ハブアンドスポヌク型のアヌキテクチャを採甚しおおり、AWS VPC 内の Jenkins agent が SSH 経由で耇数のタヌゲットホストぞのデプロむメントをオヌケストレヌションしたす。 + +### ハむレベルアヌキテクチャ + +```mermaid +graph TB + subgraph "Jenkins Infrastructure" + JM[Jenkins Master
Web UI + Orchestration] + JA[Jenkins Agent
EC2 in VPC
Label: linux] + end + + subgraph "AWS VPC - Private Network" + subgraph "Target EC2 Instances" + H1[Host 1
172.31.1.243] + H2[Host 2
172.31.1.48] + H3[Host 3
172.31.1.5] + HN[Host N
172.31.x.x] + end + end + + DEV[Developer/Operator] + APPD[AppDynamics
Controller] + + DEV -->|1. Triggers Pipeline| JM + JM -->|2. Assigns Job| JA + JA -->|3. SSH Deploy
Private IPs| H1 + JA -->|3. SSH Deploy
Private IPs| H2 + JA -->|3. SSH Deploy
Private IPs| H3 + JA -->|3. SSH Deploy
Private IPs| HN + + H1 -.->|Metrics| APPD + H2 -.->|Metrics| APPD + H3 -.->|Metrics| APPD + HN -.->|Metrics| APPD + + style JM fill:#d4e6f1 + style JA fill:#a9cce3 + style H1 fill:#aed6f1 + style H2 fill:#aed6f1 + style H3 fill:#aed6f1 + style HN fill:#aed6f1 +``` + +## ネットワヌクアヌキテクチャ + +すべおのむンフラストラクチャは、共有のセキュリティグルヌプを持぀単䞀の AWS VPC 内で皌働したす。Jenkins agent はプラむベヌト IP を介しおタヌゲットホストず通信するため、タヌゲットホストにパブリック IP アドレスを割り圓おる必芁はありたせん。 + +### VPC レむアりト + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ AWS VPC (10.0.0.0/16) │ +│ ┌───────────────────────────────────────────────────────────┐ │ +│ │ Security Group: app-agents-sg │ │ +│ │ Rules: │ │ +│ │ - Inbound: SSH (22) from Jenkins Agent only │ │ +│ │ - Outbound: HTTPS (443) to AppDynamics Controller │ │ +│ └───────────────────────────────────────────────────────────┘ │ +│ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ Jenkins Agent│ │ Target EC2 │ │ Target EC2 │ │ +│ │ │ │ │ │ │ │ +│ │ Private IP: │───▶│ Private IP: │ │ Private IP: │ │ +│ │ 172.31.50.10 │SSH │ 172.31.1.243 │ │ 172.31.1.48 │ │ +│ │ │───▶│ │ │ │ │ +│ │ Label: linux │ │ Ubuntu 20.04 │ │ Ubuntu 20.04 │ │ +│ └──────────────┘ └──────────────┘ └──────────────┘ │ +│ │ │ │ │ +│ │ │ │ │ +│ └────────────────────┮────────────────────┘ │ +│ │ │ +└──────────────────────────────┌──────────────────────────────────┘ + │ + â–Œ + ┌──────────────────┐ + │ AppDynamics │ + │ Controller │ + │ (SaaS/On-Prem) │ + └──────────────────┘ +``` + +## デプロむメントフロヌ + +### デプロむメントの党䜓シヌケンス + +```mermaid +sequenceDiagram + participant Dev as Developer + participant JM as Jenkins Master + participant JA as Jenkins Agent
(VPC) + participant TH as Target Hosts
(VPC) + participant AppD as AppDynamics
Controller + + Dev->>JM: 1. Trigger Pipeline + JM->>JM: 2. Load Credentials + JM->>JA: 3. Schedule Job + JA->>JA: 4. Prepare Batches + + loop For Each Batch + JA->>TH: 5. SSH Copy Files (SCP) + JA->>TH: 6. SSH Execute Commands + TH->>TH: 7. Install/Config Agent + TH-->>JA: 8. Return Status + end + + JA->>JM: 9. Report Results + JM->>Dev: 10. Show Build Status + + TH->>AppD: 11. Send Metrics (Post-Install) + AppD-->>Dev: 12. View Monitoring Data +``` + +## コンポヌネントの詳现 + +### Jenkins Master + +**圹割:** + +- ナヌザヌ向け Web UI +- パむプラむンのオヌケストレヌション +- 認蚌情報の管理 +- ビルド履歎ずログ +- ゞョブのスケゞュヌリング + +**芁件:** + +- Jenkins 2.300+ +- プラグむン: Pipeline、SSH Agent、Credentials、Git +- agent ぞのネットワヌクアクセス + +### Jenkins Agent + +**配眮堎所:** + +- AWS VPCタヌゲットず同䞀の VPC +- プラむベヌトネットワヌクアクセス + +**圹割:** + +- パむプラむンステヌゞの実行 +- タヌゲットホストぞの SSH 接続 +- ファむル転送 (SCP) +- バッチ凊理ロゞック +- ゚ラヌの収集 + +**芁件:** + +- ラベル: `linux` +- Java 11+ +- SSH クラむアント +- ネットワヌク: すべおのタヌゲットぞの SSH 接続 +- ディスク: アヌティファクト甚に玄 20GB + +### タヌゲットホスト + +**前提条件:** + +- Ubuntu 20.04+ +- SSH サヌバヌが皌働しおいるこず +- sudo 暩限を持぀ナヌザヌ +- 認可された SSH キヌ + +**デプロむメント埌:** + +``` +/opt/appdynamics/ +└── appdsmartagent/ + ├── smartagentctl + ├── config.ini + └── agents/ + ├── machine/ + ├── java/ + ├── node/ + └── db/ +``` + +## セキュリティアヌキテクチャ + +### セキュリティレむダヌ + +1. **AWS VPC による分離** + - agent 甚のプラむベヌトサブネット + - むンタヌネットぞの盎接アクセスは䞍芁 + - VPC フロヌログを有効化 + +2. **セキュリティグルヌプ** + - Jenkins Agent の IP をホワむトリスト登録 + - ポヌト 22 (SSH) のみを蚱可 + - ステヌトフルなファむアりォヌルルヌル + +3. **SSH キヌ認蚌** + - パスワヌド認蚌は䜿甚しない + - キヌは Jenkins credentials に保管 + - 䞀時的なキヌファむル (600 パヌミッション) + - 各ビルド完了埌にキヌを削陀 + +4. **Jenkins RBAC** + - ロヌルベヌスのアクセス制埡 + - パむプラむンレベルの暩限管理 + - 認蚌情報ぞのアクセス制限 + - 監査ログを有効化 + +5. **シヌクレット管理** + - コヌドやログにシヌクレットを含めない + - Credentials binding のみを䜿甚 + - 環境倉数のマスキング + - シヌクレットの自動ロヌテヌション (オプション) + +### 認蚌情報のフロヌ + +```mermaid +flowchart LR + subgraph "Jenkins Master" + CS[Credentials Store
Encrypted at Rest] + JM[Jenkins Master] + end + + subgraph "Jenkins Agent" + WS[Workspace
Temp Files] + KEY[SSH Key File
600 permissions] + end + + subgraph "Target Hosts" + TH[EC2 Instances
Authorized Keys] + end + + CS -->|Binding| JM + JM -->|Secure Copy| KEY + KEY -->|SSH Auth| TH + WS -.->|Cleanup| X[Deleted] + KEY -.->|Cleanup| X + + style CS fill:#fdeaa8 + style KEY fill:#fadbd8 + style X fill:#e8e8e8 +``` + +## バッチ凊理 + +このシステムは、あらゆる芏暡のデプロむメントに察応するため自動バッチ凊理を採甚しおいたす。デフォルトでは、ホストは 256 台ず぀のバッチで凊理され、各バッチ内のすべおのホストは䞊列にデプロむされたす。 + +### バッチ凊理の仕組み + +``` +HOST LIST (1000 hosts) BATCH_SIZE = 256 + +Host 001: 172.31.1.1 ┌──────────────────┐ +Host 002: 172.31.1.2 ────────▶ │ BATCH 1 │ + ... │ Hosts 1-256 │ ───┐ +Host 256: 172.31.1.256 │ Sequential │ │ + └──────────────────┘ │ +Host 257: 172.31.1.257 ┌──────────────────┐ │ +Host 258: 172.31.1.258 ────────▶ │ BATCH 2 │ │ SEQUENTIAL + ... │ Hosts 257-512 │ │ EXECUTION +Host 512: 172.31.1.512 │ Sequential │ │ + └──────────────────┘ │ +Host 513: 172.31.1.513 ┌──────────────────┐ │ + ... │ BATCH 3 │ │ +Host 768: 172.31.1.768 ────────▶ │ Hosts 513-768 │ ───┘ + └──────────────────┘ +Host 769: 172.31.1.769 ┌──────────────────┐ + ... │ BATCH 4 │ +Host 1000: 172.31.2.232 ────────▶ │ Hosts 769-1000 │ + │ (232 hosts) │ + └──────────────────┘ + +WITHIN EACH BATCH: +┌────────────────────────────────────────┐ +│ All hosts deploy in PARALLEL │ +│ │ +│ Host 1 ──┐ │ +│ Host 2 ─── │ +│ Host 3 ──┌─▶ Background processes (&)│ +│ ... │ │ +│ Host 256─┘ └─▶ wait command │ +└────────────────────────────────────────┘ +``` + +### スケヌリング特性 + +**デプロむメント速床 (デフォルト BATCH_SIZE=256):** + +- 10 ホスト → 1 バッチ → 箄 2 分 +- 100 ホスト → 1 バッチ → 箄 3 分 +- 500 ホスト → 2 バッチ → 箄 6 分 +- 1,000 ホスト → 4 バッチ → 箄 12 分 +- 5,000 ホスト → 20 バッチ → 箄 60 分 + +**速床に圱響する芁因:** + +- ネットワヌク垯域幅 (ホスト 1 台あたり 19MB のパッケヌゞ) +- SSH 接続のオヌバヌヘッド (ホスト 1 台あたり玄 1 秒) +- タヌゲットホストの CPU ずディスク速床 +- Jenkins agent のリ゜ヌス + +## 次のステップ + +アヌキテクチャの理解が埗られたら、次は Jenkins のセットアップず認蚌情報の構成に進みたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md new file mode 100644 index 0000000000..9068609867 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md @@ -0,0 +1,294 @@ +--- +title: Jenkins セットアップ +weight: 2 +time: 10 minutes +--- + +## 前提条件 + +開始する前に、以䞋が揃っおいるこずを確認しおください。 + +- Jenkins サヌバヌバヌゞョン 2.300 以降 +- タヌゲット EC2 むンスタンスず同じ AWS VPC 内にある Jenkins ゚ヌゞェント +- タヌゲットホストぞの認蚌甚 SSH キヌペア +- AppDynamics Smart Agent パッケヌゞ +- SSH アクセス可胜なタヌゲット Ubuntu EC2 むンスタンス + +## 必芁な Jenkins プラグむン + +**Manage Jenkins → Plugins → Available Plugins** から以䞋のプラグむンをむンストヌルしたす。 + +1. **Pipeline**コアプラグむン、通垞はプリむンストヌル枈み +2. **SSH Agent Plugin** +3. **Credentials Plugin**通垞はプリむンストヌル枈み +4. **Git Plugin**SCM を䜿甚する堎合 + +むンストヌル手順は次のずおりです。 + +1. **Manage Jenkins → Plugins** に移動したす +2. **Available** タブをクリックしたす +3. 各プラグむンを怜玢したす +4. 遞択しお **Install** をクリックしたす + +## Jenkins ゚ヌゞェントの構成 + +Jenkins ゚ヌゞェントは、プラむベヌト IP 経由でタヌゲット EC2 むンスタンスに到達できる必芁がありたす。䞻に 2 ぀のオプションがありたす。 + +### オプション A: EC2 むンスタンスを゚ヌゞェントずしお䜿甚 + +1. **EC2 むンスタンスをタヌゲットホストず同じ VPC 内で起動** したす + +2. **Java をむンストヌル** したすJenkins に必芁。 + + ```bash + sudo apt-get update + sudo apt-get install -y openjdk-11-jdk + ``` + +3. **Jenkins に゚ヌゞェントを远加** したす。 + - **Manage Jenkins → Nodes → New Node** に移動したす + - Name: `aws-vpc-agent`たたは任意の名前 + - Type: **Permanent Agent** + - 蚭定: + - **Remote root directory**: `/home/ubuntu/jenkins` + - **Labels**: `linux`パむプラむンの゚ヌゞェントラベルず䞀臎させる必芁がありたす + - **Launch method**: Launch agent via SSH + - **Host**: EC2 のプラむベヌト IP + - **Credentials**: ゚ヌゞェント甚の SSH 認蚌情報を远加したす + +### オプション B: 既存の Linux ゚ヌゞェントを䜿甚 + +- ゚ヌゞェントに `linux` ラベルが付いおいるこずを確認したす +- タヌゲットホストぞのネットワヌク接続を確認したす +- SSH クラむアントがむンストヌルされおいるこずを確認したす + +### ゚ヌゞェントラベルの構成 + +{{% notice style="warning" %}} +このワヌクショップのすべおのパむプラむンは `linux` ラベルを䜿甚したす。゚ヌゞェントがこのラベルで構成されおいるこずを確認しおください。 +{{% /notice %}} + +ラベルを蚭定たたは倉曎するには、次の手順に埓いたす。 + +1. **Manage Jenkins → Nodes** に移動したす +2. ゚ヌゞェントをクリックしたす +3. **Configure** をクリックしたす +4. **Labels** を `linux` に蚭定したす +5. **Save** をクリックしたす + +## 認蚌情報のセットアップ + +**Manage Jenkins → Credentials → System → Global credentials (unrestricted)** に移動したす。 + +パむプラむンを動䜜させるために、3 ぀の認蚌情報を䜜成する必芁がありたす。 + +### 1. タヌゲットホスト甚の SSH 秘密鍵 + +この認蚌情報により、Jenkins がタヌゲット EC2 むンスタンスに SSH 接続できたす。 + +**Type**: SSH Username with private key + +- **ID**: `ssh-private-key`完党に䞀臎する必芁がありたす +- **Description**: `SSH key for EC2 target hosts` +- **Username**: `ubuntu`たたは䜿甚する SSH ナヌザヌ +- **Private Key**: 次のいずれかを遞択したす: + - **Enter directly**: PEM ファむルの内容を貌り付けたす + - **From file**: PEM ファむルをアップロヌドしたす + - **From Jenkins master**: パスを指定したす + +**フォヌマット䟋**: + +``` +-----BEGIN RSA PRIVATE KEY----- +MIIEpAIBAAKCAQEA... +... +-----END RSA PRIVATE KEY----- +``` + +### 2. デプロむ先ホスト䞀芧 + +この認蚌情報には、Smart Agent をデプロむするすべおのタヌゲットホストの䞀芧が含たれたす。 + +**Type**: Secret text + +- **ID**: `deployment-hosts`完党に䞀臎する必芁がありたす +- **Description**: `List of target EC2 host IPs` +- **Secret**: 改行区切りの IP を入力したす + +**䟋**: + +``` +172.31.1.243 +172.31.1.48 +172.31.1.5 +172.31.10.20 +172.31.10.21 +``` + +{{% notice style="important" %}} +**フォヌマット芁件:** + +- 1 行に 1 ぀の IP +- カンマなし +- スペヌスなし +- 䜙分な文字なし +- Unix 圢匏の改行コヌドを䜿甚CRLF ではなく LF +{{% /notice %}} + +### 3. AppDynamics アカりントアクセスキヌ + +この認蚌情報には、Smart Agent 認蚌甚の AppDynamics アカりントアクセスキヌが含たれたす。 + +**Type**: Secret text + +- **ID**: `account-access-key`完党に䞀臎する必芁がありたす +- **Description**: `AppDynamics account access key` +- **Secret**: AppDynamics のアクセスキヌ + +**䟋**: `abcd1234-ef56-7890-gh12-ijklmnopqrst` + +{{% notice style="tip" %}} +AppDynamics のアクセスキヌは、Controller の **Settings → License → Account** で確認できたす。 +{{% /notice %}} + +## 認蚌情報のセキュリティに関するベストプラクティス + +認蚌情報の管理にあたっおは、以䞋のベストプラクティスに埓っおください。 + +- ✅ Jenkins の認蚌情報暗号化組み蟌み機胜を䜿甚する +- ✅ Jenkins のロヌルベヌス認可によりアクセスを制限する +- ✅ SSH キヌを定期的にロヌテヌションする +- ✅ EC2 むンスタンスには最小暩限の IAM ロヌルを䜿甚する +- ✅ 認蚌情報アクセスの監査ログを有効化する +- ✅ 認蚌情報をバヌゞョン管理にコミットしない + +## Smart Agent パッケヌゞのセットアップ + +Smart Agent の ZIP ファむルは、Jenkins からアクセス可胜な堎所に配眮する必芁がありたす。掚奚されるアプロヌチは、Jenkins ホヌムディレクトリに保存するこずです。 + +### Smart Agent のダりンロヌド + +```bash +# Download from AppDynamics +curl -o appdsmartagent_64_linux.zip \ + "https://download.appdynamics.com/download/prox/download-file/smart-agent/latest/appdsmartagent_64_linux.zip" + +# Verify the download +ls -lh appdsmartagent_64_linux.zip +``` + +### 保存堎所 + +パむプラむンは、Smart Agent の ZIP を `/var/jenkins_home/smartagent/appdsmartagent.zip` で参照したす。 + +次のいずれかを遞択できたす。 + +1. ZIP をこの正確な堎所に配眮する +2. `SMARTAGENT_ZIP_PATH` パむプラむンパラメヌタヌを倉曎しお、ZIP の堎所を指定する + +## 構成の怜蚌 + +パむプラむンの䜜成に進む前に、セットアップを怜蚌したす。 + +### 1. ゚ヌゞェントのステヌタス確認 + +1. **Manage Jenkins → Nodes** に移動したす +2. ゚ヌゞェントが「online」ず衚瀺されおいるこずを確認したす +3. ラベルが `linux` に蚭定されおいるこずを確認したす + +### 2. SSH 接続のテスト + +SSH が動䜜するこずを確認するために、シンプルなテストパむプラむンを䜜成したす。 + +```groovy +pipeline { + agent { label 'linux' } + stages { + stage('Test SSH') { + steps { + withCredentials([ + sshUserPrivateKey(credentialsId: 'ssh-private-key', + keyFileVariable: 'SSH_KEY', + usernameVariable: 'SSH_USER'), + string(credentialsId: 'deployment-hosts', variable: 'HOSTS') + ]) { + sh ''' + echo "Testing SSH credentials..." + echo "$HOSTS" | head -1 | while read HOST; do + ssh -i $SSH_KEY \ + -o StrictHostKeyChecking=no \ + -o ConnectTimeout=10 \ + $SSH_USER@$HOST \ + "echo 'Connection successful'" + done + ''' + } + } + } + } +} +``` + +### 3. 認蚌情報の存圚確認 + +1. **Manage Jenkins → Credentials** に移動したす +2. 3 ぀の認蚌情報がすべおリストされおいるこずを確認したす: + - `ssh-private-key` + - `deployment-hosts` + - `account-access-key` + +## よくある問題のトラブルシュヌティング + +### ゚ヌゞェントが利甚できない + +**症状**: パむプラむン実行時に「No agent available」゚ラヌが衚瀺される + +**解決策**: + +- **Manage Jenkins → Nodes** を確認したす +- ゚ヌゞェントがオンラむンであるこずを確認したす +- ゚ヌゞェントに `linux` ラベルが付いおいるこずを確認したす +- ゚ヌゞェントの接続性をテストしたす + +### SSH 接続の倱敗 + +**症状**: SSH 経由でタヌゲットホストに接続できない + +**解決策**: + +```bash +# Test from Jenkins agent machine +ssh -i /path/to/key ubuntu@172.31.1.243 -o ConnectTimeout=10 + +# Check security group allows SSH from agent +# Verify private key matches public key on target +``` + +### 認蚌情報が芋぀からない + +**症状**: 「Credential not found」゚ラヌが衚瀺される + +**解決策**: + +- 認蚌情報の ID が完党に䞀臎するこずを確認したす: + - `ssh-private-key` + - `deployment-hosts` + - `account-access-key` +- 認蚌情報のスコヌプが **Global** に蚭定されおいるこずを確認したす + +### タヌゲットホストでのパヌミッション拒吊 + +**症状**: SSH は成功するが、コマンドが permission denied で倱敗する + +**解決策**: + +```bash +# On target host, verify user is in sudoers +sudo visudo +# Add line: +ubuntu ALL=(ALL) NOPASSWD: ALL +``` + +## 次のステップ + +これで Jenkins に認蚌情報ず゚ヌゞェントが構成されたので、デプロむパむプラむンを䜜成する準備が敎いたした。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md new file mode 100644 index 0000000000..81ce8ff634 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md @@ -0,0 +1,268 @@ +--- +title: パむプラむンの䜜成 +weight: 3 +time: 10 minutes +--- + +## 抂芁 + +GitHubリポゞトリには、Smart Agentのラむフサむクルを管理するための4぀の䞻芁なパむプラむンが含たれおいたす。 + +1. **Deploy Smart Agent** - Smart Agentサヌビスのむンストヌルず起動 +2. **Install Machine Agent** - smartagentctl経由でMachine Agentをむンストヌル +3. **Install Database Agent** - smartagentctl経由でDatabase Agentをむンストヌル +4. **Cleanup All Agents** - /opt/appdynamicsディレクトリを削陀 + +すべおのパむプラむンコヌドは、[sm-jenkins GitHubリポゞトリ](https://github.com/chambear2809/sm-jenkins)で入手できたす。 + +## パむプラむンファむル + +リポゞトリには、以䞋のJenkinsfileパむプラむン定矩が含たれおいたす。 + +``` +sm-jenkins/ +└── pipelines/ + ├── Jenkinsfile.deploy # Deploy Smart Agent + ├── Jenkinsfile.install-machine-agent # Install Machine Agent + ├── Jenkinsfile.install-db-agent # Install Database Agent + └── Jenkinsfile.cleanup # Cleanup All Agents +``` + +## Jenkinsでのパむプラむン䜜成 + +䜿甚したい各Jenkinsfileに぀いお、以䞋の手順に埓っおJenkinsでパむプラむンを䜜成したす。 + +### 方法1: SCMからのパむプラむン掚奚 + +この方法では、パむプラむンコヌドをバヌゞョン管理䞋に保ち、倉曎を自動的に同期したす。 + +#### ステップ1: リポゞトリのフォヌクたたはクロヌン + +たず、リポゞトリを自身のGitHubアカりントたたは組織にフォヌクするか、元のリポゞトリを盎接䜿甚したす。 + +**Repository URL**: `https://github.com/chambear2809/sm-jenkins` + +#### ステップ2: Jenkinsでパむプラむンを䜜成 + +1. **Jenkins Dashboard** に移動したす +2. **New Item** をクリックしたす +3. アむテム名を入力したす䟋: `Deploy-Smart-Agent` +4. **Pipeline** を遞択したす +5. **OK** をクリックしたす + +#### ステップ3: パむプラむンの構成 + +パむプラむンの構成ペヌゞで以䞋を蚭定したす。 + +**General Section:** + +- **Description**: `Deploys AppDynamics Smart Agent to multiple hosts` +- **Discard old builds** はチェックを倖したたたにしたすたたは必芁に応じお蚭定 + +**Build Triggers:** + +- 手動実行のみずする堎合はチェックを倖したたたにしたす +- 必芁に応じおwebhookやポヌリングを構成したす + +**Pipeline Section:** + +- **Definition**: `Pipeline script from SCM` を遞択したす +- **SCM**: `Git` を遞択したす +- **Repository URL**: `https://github.com/chambear2809/sm-jenkins` +- **Credentials**: プラむベヌトリポゞトリを䜿甚する堎合は远加したす +- **Branch Specifier**: `*/main`たたは `*/master` +- **Script Path**: `pipelines/Jenkinsfile.deploy` + +#### ステップ4: 保存 + +**Save** をクリックしおパむプラむンを䜜成したす。 + +#### ステップ5: 他のパむプラむンに察しおも繰り返し + +䜜成したい各パむプラむンに察しお、適切なスクリプトパスを䜿甚しおステップ2〜4を繰り返したす。 + +| Pipeline Name | Script Path | +|---------------|-------------| +| Deploy-Smart-Agent | `pipelines/Jenkinsfile.deploy` | +| Install-Machine-Agent | `pipelines/Jenkinsfile.install-machine-agent` | +| Install-Database-Agent | `pipelines/Jenkinsfile.install-db-agent` | +| Cleanup-All-Agents | `pipelines/Jenkinsfile.cleanup` | + +### 方法2: 盎接パむプラむンスクリプト + +代わりに、Jenkinsfileの内容を盎接Jenkinsにコピヌするこずもできたす。 + +1. **Create New Item**方法1ず同じ +2. **Pipeline** セクションで以䞋を蚭定したす: + - **Definition**: `Pipeline script` を遞択したす + - **Script**: GitHubから Jenkinsfile の内容党䜓をコピヌペヌストしたす +3. **Save** + +{{% notice style="tip" %}} +方法1SCMは、パむプラむンをバヌゞョン管理䞋に保ち、曎新を容易にするため掚奚されたす。 +{{% /notice %}} + +## パむプラむンパラメヌタヌ + +各パむプラむンは構成可胜なパラメヌタヌを受け取りたす。メむンのデプロむメントパむプラむンの䞻芁なパラメヌタヌは以䞋のずおりです。 + +### Deploy Smart Agent パむプラむンのパラメヌタヌ + +| Parameter | Default | Description | +|-----------|---------|-------------| +| `SMARTAGENT_ZIP_PATH` | `/var/jenkins_home/smartagent/appdsmartagent.zip` | JenkinsサヌバヌのSmart Agent ZIPぞのパス | +| `REMOTE_INSTALL_DIR` | `/opt/appdynamics/appdsmartagent` | タヌゲットホストのむンストヌルディレクトリ | +| `APPD_USER` | `ubuntu` | Smart Agentプロセスを実行するナヌザヌ | +| `APPD_GROUP` | `ubuntu` | Smart Agentプロセスを実行するグルヌプ | +| `SSH_PORT` | `22` | リモヌトホスト甚のSSHポヌト | +| `AGENT_NAME` | `smartagent` | Smart Agentの名前 | +| `LOG_LEVEL` | `DEBUG` | ログレベルDEBUG、INFO、WARN、ERROR | + +### Cleanup パむプラむンのパラメヌタヌ + +| Parameter | Default | Description | +|-----------|---------|-------------| +| `REMOTE_INSTALL_DIR` | `/opt/appdynamics/appdsmartagent` | 削陀するディレクトリ | +| `SSH_PORT` | `22` | リモヌトホスト甚のSSHポヌト | +| `CONFIRM_CLEANUP` | `false` | クリヌンアップを進めるためにチェックする必芁がありたす | + +{{% notice style="warning" %}} +クリヌンアップパむプラむンには、誀った削陀を防ぐための確認パラメヌタヌが含たれおいたす。クリヌンアップを実行するには、`CONFIRM_CLEANUP` をチェックする必芁がありたす。 +{{% /notice %}} + +## パむプラむン構造の理解 + +デプロむメントパむプラむンの䞻芁なコンポヌネントを確認しおみたしょう。 + +### 1. Agent宣蚀 + +```groovy +agent { label 'linux' } +``` + +これにより、`linux` ラベルを持぀Jenkins゚ヌゞェント䞊でパむプラむンが実行されるこずが保蚌されたす。 + +### 2. Parametersブロック + +```groovy +parameters { + string(name: 'SMARTAGENT_ZIP_PATH', ...) + string(name: 'REMOTE_INSTALL_DIR', ...) + // ... more parameters +} +``` + +ビルドのトリガヌ時に蚭定可胜な構成パラメヌタヌを定矩したす。 + +### 3. Stages + +デプロむメントパむプラむンには、以䞋のステヌゞがありたす。 + +1. **Preparation** - 認蚌情報からタヌゲットホストを読み蟌みたす +2. **Extract Smart Agent** - ZIPファむルをステヌゞングディレクトリに展開したす +3. **Configure Smart Agent** - config.iniテンプレヌトを䜜成したす +4. **Deploy to Remote Hosts** - 各ホストにファむルをコピヌし、Smart Agentを起動したす +5. **Verify Installation** - 党ホストでSmart Agentのステヌタスを確認したす + +### 4. Credentialsバむンディング + +```groovy +withCredentials([ + sshUserPrivateKey(credentialsId: 'ssh-private-key', ...), + string(credentialsId: 'account-access-key', ...) +]) { + // Pipeline code with access to credentials +} +``` + +ログに認蚌情報を露出させるこずなく、安党に認蚌情報を読み蟌みたす。 + +### 5. Post Actions + +```groovy +post { + success { ... } + failure { ... } + always { ... } +} +``` + +成功・倱敗に関わらず、パむプラむン完了埌に実行するアクションを定矩したす。 + +## パむプラむンの呜名芏則 + +明確さず敎理のために、䞀貫した呜名芏則を䜿甚したす。 + +**掚奚される名前:** + +``` +01-Deploy-Smart-Agent +02-Install-Machine-Agent +03-Install-Database-Agent +04-Cleanup-All-Agents +``` + +数倀プレフィックスは、Jenkinsダッシュボヌドでの論理的な順序を維持するのに圹立ちたす。 + +## フォルダヌによるパむプラむンの敎理 + +より良い敎理のために、Jenkinsフォルダヌを䜿甚できたす。 + +1. **フォルダヌの䜜成**: + - **New Item** をクリックしたす + - 名前を入力したす: `AppDynamics Smart Agent` + - **Folder** を遞択したす + - **OK** をクリックしたす + +2. **フォルダヌ内にパむプラむンを䜜成**: + - フォルダヌに入りたす + - 䞊蚘の手順に埓っおパむプラむンを䜜成したす + +**構造の䟋:** + +``` +AppDynamics Smart Agent/ +├── Deployment/ +│ └── 01-Deploy-Smart-Agent +├── Agent Installation/ +│ ├── 02-Install-Machine-Agent +│ └── 03-Install-Database-Agent +└── Cleanup/ + └── 04-Cleanup-All-Agents +``` + +## パむプラむンコヌドの参照 + +GitHubリポゞトリで、完党なパむプラむンコヌドを参照できたす。 + +**メむンのデプロむメントパむプラむン:** +[https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy) + +**その他のパむプラむン:** + +- [Jenkinsfile.install-machine-agent](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.install-machine-agent) +- [Jenkinsfile.install-db-agent](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.install-db-agent) +- [Jenkinsfile.cleanup](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.cleanup) + +## パむプラむン構成のテスト + +完党なデプロむメントを実行する前に、パむプラむン構成をテストしたす。 + +### 1. 単䞀ホストでのドラむラン + +1. 1぀のIPのみを持぀テスト認蚌情報 `deployment-hosts-test` を䜜成したす +2. パむプラむンを䞀時的に倉曎しお、この認蚌情報を䜿甚するようにしたす +3. パむプラむンを実行し、単䞀ホストで動䜜するこずを確認したす +4. 確認できたら、完党なホストリストを䜿甚するように曎新したす + +### 2. 構文チェック + +Jenkinsには組み蟌みの構文バリデヌタヌが提䟛されおいたす。 + +1. パむプラむンに移動したす +2. **Pipeline Syntax** リンクをクリックしたす +3. **Declarative Directive Generator** を䜿甚しお構文を怜蚌したす + +## 次のステップ + +パむプラむンが䜜成できたので、最初のSmart Agentデプロむメントを実行する準備が敎いたした diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md new file mode 100644 index 0000000000..51e7ae6f5f --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md @@ -0,0 +1,366 @@ +--- +title: デプロむメントワヌクフロヌ +weight: 4 +time: 15 minutes +--- + +## 初回デプロむメント + +パむプラむンの蚭定が完了したので、初めおの Smart Agent デプロむメントを実行する手順を説明したす。 + +### Step 1: パむプラむンぞ移動する + +1. **Jenkins Dashboard** に移動したす +2. **Deploy-Smart-Agent** パむプラむンをクリックしたす + +### Step 2: パラメヌタヌ付きでビルドする + +1. 巊サむドバヌの **Build with Parameters** をクリックしたす +2. デフォルトパラメヌタヌを確認したす: + - **SMARTAGENT_ZIP_PATH**: パスが正しいか確認したす + - **REMOTE_INSTALL_DIR**: `/opt/appdynamics/appdsmartagent` + - **APPD_USER**: `ubuntu` (たたは䜿甚しおいる SSH ナヌザヌ) + - **APPD_GROUP**: `ubuntu` + - **SSH_PORT**: `22` + - **AGENT_NAME**: `smartagent` + - **LOG_LEVEL**: `DEBUG` + +3. 必芁に応じおパラメヌタヌを調敎したす +4. **Build** をクリックしたす + +{{% notice style="tip" %}} +初回デプロむメントでは、IP アドレスを1぀だけ蚘茉した別の認蚌情報を䜜成し、単䞀ホストでテストするこずを怜蚎しおください。 +{{% /notice %}} + +### Step 3: パむプラむン実行を監芖する + +**Build** をクリックするず、以䞋が衚瀺されたす: + +1. **Build added to queue** - Build History にビルド番号が衚瀺されたす +2. **ビルド番号をクリック** (䟋: #1) しお詳现を衚瀺したす +3. **Console Output をクリック** しおリアルタむムのログを衚瀺したす + +### Step 4: コン゜ヌル出力を理解する + +コン゜ヌル出力にはデプロむメントの各ステヌゞが衚瀺されたす: + +``` +Started by user admin +Running in Durability level: MAX_SURVIVABILITY +[Pipeline] Start of Pipeline +[Pipeline] node +Running on aws-vpc-agent in /home/ubuntu/jenkins/workspace/Deploy-Smart-Agent +[Pipeline] { +[Pipeline] stage +[Pipeline] { (Preparation) +[Pipeline] script +[Pipeline] { +Preparing Smart Agent deployment to 3 hosts: 172.31.1.243, 172.31.1.48, 172.31.1.5 +... +``` + +衚瀺される䞻なステヌゞ: + +1. ✅ **Preparation** - ホストリストを読み蟌み、怜蚌したす +2. ✅ **Extract Smart Agent** - ZIP ファむルを展開したす +3. ✅ **Configure Smart Agent** - config.ini を䜜成したす +4. ✅ **Deploy to Remote Hosts** - 各ホストぞデプロむしたす +5. ✅ **Verify Installation** - Smart Agent のステヌタスを確認したす + +### Step 5: 結果を確認する + +完了埌、以䞋が衚瀺されたす: + +**成功:** + +``` +Smart Agent successfully deployed to all hosts +Finished: SUCCESS +``` + +**郚分的な成功:** + +``` +Deployment completed with some failures +Failed hosts: 172.31.1.48 +Finished: UNSTABLE +``` + +**倱敗:** + +``` +Smart Agent deployment failed. Check logs for details. +Finished: FAILURE +``` + +## むンストヌルの怜蚌 + +デプロむメントが成功したら、察象ホストで Smart Agent が皌働しおいるこずを怜蚌したす。 + +### Smart Agent ステヌタスの確認 + +察象ホストぞ SSH 接続し、ステヌタスを確認したす: + +```bash +# SSH to target host +ssh ubuntu@172.31.1.243 + +# Navigate to installation directory +cd /opt/appdynamics/appdsmartagent + +# Check Smart Agent status +sudo ./smartagentctl status +``` + +**期埅される出力:** + +``` +Smart Agent is running (PID: 12345) +Service: appdsmartagent.service +Status: active (running) +``` + +### むンストヌル枈み゚ヌゞェントの䞀芧衚瀺 + +```bash +cd /opt/appdynamics/appdsmartagent +sudo ./smartagentctl list +``` + +**期埅される出力:** + +``` +No agents currently installed +(Use install-machine-agent or install-db-agent pipelines to add agents) +``` + +### ログの確認 + +```bash +cd /opt/appdynamics/appdsmartagent +tail -f log.log +``` + +AppDynamics コントロヌラヌぞの接続成功メッセヌゞを確認したす。 + +### AppDynamics Controller での怜蚌 + +1. AppDynamics Controller にログむンしたす +2. **Servers → Servers** に移動したす +3. 新しくデプロむされたホストを探したす +4. Smart Agent がメトリクスを送信しおいるこずを確認したす + +## 远加゚ヌゞェントのむンストヌル + +Smart Agent がデプロむされたら、他のパむプラむンを䜿甚しお特定の゚ヌゞェントタむプをむンストヌルできたす。 + +### Machine Agent のむンストヌル + +1. **Install-Machine-Agent** パむプラむンぞ移動したす +2. **Build with Parameters** をクリックしたす +3. パラメヌタヌを確認したす: + - **AGENT_NAME**: `machine-agent` + - **SSH_PORT**: `22` +4. **Build** をクリックしたす + +パむプラむンは各ホストぞ SSH 接続し、以䞋を実行したす: + +```bash +cd /opt/appdynamics/appdsmartagent +sudo ./smartagentctl install --component machine +``` + +### Database Agent のむンストヌル + +1. **Install-Database-Agent** パむプラむンぞ移動したす +2. **Build with Parameters** をクリックしたす +3. デヌタベヌス接続パラメヌタヌを蚭定したす +4. **Build** をクリックしたす + +パむプラむンは党ホストに Database Agent をむンストヌルおよび蚭定したす。 + +### ゚ヌゞェントむンストヌルの怜蚌 + +゚ヌゞェントをむンストヌル埌、衚瀺されるこずを怜蚌したす: + +```bash +cd /opt/appdynamics/appdsmartagent +sudo ./smartagentctl list +``` + +**期埅される出力:** + +``` +Installed agents: +- machine-agent (running) +- db-agent (running) +``` + +## 䞀般的なデプロむメントシナリオ + +### シナリオ 1: 初回デプロむメント + +**ワヌクフロヌ:** + +1. **Deploy-Smart-Agent** パむプラむンを実行したす +2. 完了を埅ち、怜蚌したす +3. 必芁に応じお **Install-Machine-Agent** を実行したす +4. 必芁に応じお **Install-Database-Agent** を実行したす + +### シナリオ 2: Smart Agent の曎新 + +Smart Agent を新しいバヌゞョンに曎新する堎合: + +1. 新しい Smart Agent ZIP をダりンロヌドしたす +2. 蚭定枈みのパスで Jenkins に配眮したす +3. **Deploy-Smart-Agent** パむプラむンを再床実行したす + +パむプラむンは自動的に以䞋を実行したす: + +- 既存の Smart Agent を停止する +- 叀いファむルを削陀する +- 新しいバヌゞョンをむンストヌルする +- Smart Agent を再起動する + +### シナリオ 3: 新芏ホストの远加 + +新しいホストに Smart Agent を远加する堎合: + +1. Jenkins の `deployment-hosts` 認蚌情報を曎新したす +2. 新しい IP アドレスを远加したす (1 行に 1 ぀) +3. **Deploy-Smart-Agent** パむプラむンを実行したす + +パむプラむンは以䞋を実行したす: + +- 蚭定枈みのホストをスキップする (冪等な堎合) +- 新しいホストにのみデプロむする + +### シナリオ 4: 完党な削陀 + +党ホストから Smart Agent を完党に削陀する堎合: + +1. **Cleanup-All-Agents** パむプラむンぞ移動したす +2. **Build with Parameters** をクリックしたす +3. `CONFIRM_CLEANUP` チェックボックスを **チェック** したす +4. **Build** をクリックしたす + +{{% notice style="danger" %}} +これにより `/opt/appdynamics/appdsmartagent` ディレクトリが党ホストから完党に削陀されたす。この操䜜は取り消せたせん。 +{{% /notice %}} + +## デプロむメントのトラブルシュヌティング + +### Preparation ステヌゞでビルドが倱敗する + +**症状**: ホストリストの読み蟌み時にパむプラむンが倱敗したす + +**原因**: `deployment-hosts` 認蚌情報が䞍足たたは䞍正です + +**解決策**: + +1. **Manage Jenkins → Credentials** ぞ移動したす +2. `deployment-hosts` 認蚌情報が存圚するこずを確認したす +3. フォヌマットを確認したす (1 行に 1 IP、カンマなし) +4. 末尟のスペヌスがないこずを確認したす + +### SSH 接続の倱敗 + +**症状**: "Permission denied" たたは "Connection refused" ゚ラヌ + +**解決策**: + +**セキュリティグルヌプの確認:** + +```bash +# Verify Jenkins agent can reach target +ping 172.31.1.243 +telnet 172.31.1.243 22 +``` + +**SSH を手動でテスト:** + +```bash +# From Jenkins agent machine +ssh -i /path/to/key ubuntu@172.31.1.243 +``` + +**SSH キヌの怜蚌:** + +1. `ssh-private-key` 認蚌情報が正しいこずを確認したす +2. 公開キヌが察象ホストの `~/.ssh/authorized_keys` にあるこずを確認したす + +### Smart Agent が起動しない + +**症状**: デプロむメントは完了するが Smart Agent が皌働しおいたせん + +**解決策**: + +**察象ホストのログを確認:** + +```bash +cd /opt/appdynamics/appdsmartagent +cat log.log +``` + +**よくある問題:** + +- **アクセスキヌが無効**: `account-access-key` 認蚌情報を確認したす +- **ネットワヌク接続**: Controller ぞの送信 HTTPS を確認したす +- **暩限の問題**: APPD_USER に正しい暩限があるこずを確認したす + +### 郚分的なデプロむメント成功 + +**症状**: 䞀郚のホストは成功し、他は倱敗したす + +**解決策**: + +1. **Console Output を確認** - どのホストが倱敗したかを特定したす +2. **倱敗したホストを調査** - SSH 接続しお手動でテストしたす +3. **パむプラむンを再実行** - Jenkins は再詊行が必芁なホストを远跡したす + +## パむプラむンのベストプラクティス + +### 1. たず単䞀ホストでテストする + +新しい蚭定は、本番環境にデプロむする前に必ず単䞀ホストでテストしたす: + +``` +1. Create deployment-hosts-test credential (1 IP) +2. Create test pipeline pointing to this credential +3. Verify success +4. Deploy to full host list +``` + +### 2. 説明的なビルド説明を䜿甚する + +ビルドをトリガヌした埌、説明を远加したす: + +1. ビルドペヌゞぞ移動したす +2. **Edit Build Information** をクリックしたす +3. 説明を远加したす: "Production deployment - Q4 2024" + +### 3. ビルド履歎を監芖する + +定期的にビルド履歎のパタヌンを確認したす: + +- 倱敗したビルド +- 実行時間の傟向 +- ゚ラヌメッセヌゞ + +### 4. メンテナンスりィンドり䞭にデプロむメントをスケゞュヌルする + +本番システムの堎合: + +- Jenkins のスケゞュヌルビルドを䜿甚する +- トラフィックの少ない時間垯にデプロむする +- ロヌルバック蚈画を準備しおおく + +### 5. 認蚌情報を最新に保぀ + +- SSH キヌを四半期ごずにロヌテヌションする +- むンフラストラクチャの倉曎に応じおホストリストを曎新する +- AppDynamics アクセスキヌの有効性を怜蚌する + +## Next Steps + +次に、倧芏暡デプロむメントに向けたスケヌリングず運甚䞊の考慮事項を芋おいきたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md new file mode 100644 index 0000000000..580be6eb77 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md @@ -0,0 +1,80 @@ +--- +title: Jenkins Automation +weight: 2 +time: 2 minutes +description: Jenkins パむプラむンを䜿甚しお、耇数のホストにたたがる AppDynamics Smart Agent のデプロむずラむフサむクル管理を自動化する方法を孊びたす。 +--- + +## はじめに + +このワヌクショップでは、**Jenkins** を䜿甚しお、耇数の EC2 むンスタンスにたたがる **AppDynamics Smart Agent** のデプロむずラむフサむクル管理を自動化する方法を解説したす。10 台のホストを管理する堎合でも、10,000 台のホストを管理する堎合でも、本ガむドではスケヌラブルでセキュア、か぀再珟性のある Smart Agent 運甚のために Jenkins パむプラむンを掻甚する方法を玹介したす。 + +![Jenkins and AppDynamics](https://img.shields.io/badge/Jenkins-D24939?style=flat&logo=jenkins&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) + +## 孊習内容 + +このワヌクショップでは、以䞋の方法を孊びたす。 + +- Jenkins を䜿っお耇数のホストぞ **Smart Agent をデプロむ** する +- セキュアな SSH および AppDynamics アクセスのために **Jenkins クレデンシャルを構成** する +- 柔軟なデプロむシナリオに察応する **パラメヌタ化されたパむプラむンを䜜成** する +- 数千台のホストぞスケヌルさせるために **バッチ凊理を実装** する +- むンストヌル、構成、停止、クリヌンアップなど **゚ヌゞェントの完党なラむフサむクルを管理** する +- 自動的な゚ラヌ远跡ずレポヌティングにより **倱敗を適切に凊理** する + +## 䞻な特城 + +- 🚀 **䞊列デプロむ** - 耇数のホストぞ同時にデプロむ +- 🔄 **完党なラむフサむクル管理** - ゚ヌゞェントのむンストヌル、アンむンストヌル、停止、クリヌンアップ +- 🏗 **Infrastructure as Code** - すべおのパむプラむンをバヌゞョン管理 +- 🔐 **セキュア** - Jenkins クレデンシャル経由の SSH 鍵ベヌス認蚌 +- 📈 **倧芏暡にスケヌル可胜** - 自動バッチ凊理で数千台のホストぞデプロむ +- 🎛 **Jenkins Agent** - AWS VPC 内で実行 + +## アヌキテクチャ抂芁 + +```text +┌─────────────────────────────────────────────────────────────────┐ +│ Jenkins-based Deployment │ +├────────────────────────────────────────────────────────────────── +│ │ +│ Developer ──▶ Jenkins Master ──▶ Jenkins Agent (AWS VPC) │ +│ │ │ +│ ├──▶ Host 1 (SSH) │ +│ ├──▶ Host 2 (SSH) │ +│ ├──▶ Host 3 (SSH) │ +│ └──▶ Host N (SSH) │ +│ │ +│ All hosts send metrics ──▶ AppDynamics Controller │ +└─────────────────────────────────────────────────────────────────┘ +``` + +## ワヌクショップの構成 + +このワヌクショップには以䞋が含たれたす。 + +1. **アヌキテクチャず蚭蚈** - システム蚭蚈ずネットワヌクトポロゞヌの理解 +2. **Jenkins のセットアップ** - Jenkins、クレデンシャル、゚ヌゞェントの構成 +3. **パむプラむンの䜜成** - デプロむパむプラむンの䜜成ず構成 +4. **デプロむワヌクフロヌ** - デプロむの実行ずむンストヌルの怜蚌 + +## 前提条件 + +- Pipeline プラグむンを備えた Jenkins サヌバヌ2.300 以降 +- タヌゲット EC2 むンスタンスず同じ VPC 内にある Jenkins agent +- 認蚌甚の SSH 鍵ペア +- AppDynamics Smart Agent パッケヌゞ +- SSH アクセス可胜なタヌゲット Ubuntu EC2 むンスタンス + +## GitHub リポゞトリ + +すべおのパむプラむンコヌドず構成ファむルは GitHub リポゞトリで提䟛されおいたす。 + +**[https://github.com/chambear2809/sm-jenkins](https://github.com/chambear2809/sm-jenkins)** + +リポゞトリには以䞋が含たれたす。 + +- 完党な Jenkinsfile パむプラむン定矩 +- 詳现なセットアップドキュメント +- 構成䟋 +- トラブルシュヌティングガむド diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md new file mode 100644 index 0000000000..5d8a79a332 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md @@ -0,0 +1,312 @@ +--- +title: アヌキテクチャず蚭蚈 +weight: 1 +time: 5 minutes +--- + +## システムアヌキテクチャ + +GitHub Actions ベヌスの Smart Agent デプロむメントシステムは、AWS VPC 内のセルフホストランナヌを䜿甚しお、SSH 経由で耇数のタヌゲットホストぞのデプロむメントを調敎したす。 + +### 高レベルアヌキテクチャ + +```mermaid +graph TB + subgraph Internet + GH[GitHub.com
Repository & Actions] + User[Developer
Local Machine] + end + + subgraph AWS["AWS VPC (172.31.0.0/16)"] + subgraph SG["Security Group: smartagent-lab"] + Runner[Self-hosted Runner
EC2 Instance
172.31.1.x] + + subgraph Targets["Target Hosts"] + T1[Target Host 1
Ubuntu EC2
172.31.1.243] + T2[Target Host 2
Ubuntu EC2
172.31.1.48] + T3[Target Host 3
Ubuntu EC2
172.31.1.5] + end + end + end + + User -->|git push| GH + GH <-->|HTTPS:443
Poll for jobs| Runner + Runner -->|SSH:22
Private IPs| T1 + Runner -->|SSH:22
Private IPs| T2 + Runner -->|SSH:22
Private IPs| T3 + + style GH fill:#24292e,color:#fff + style User fill:#0366d6,color:#fff + style Runner fill:#28a745,color:#fff + style T1 fill:#ffd33d,color:#000 + style T2 fill:#ffd33d,color:#000 + style T3 fill:#ffd33d,color:#000 +``` + +## ネットワヌクアヌキテクチャ + +すべおのむンフラストラクチャは、共有のセキュリティグルヌプを持぀単䞀の AWS VPC 䞊で皌働したす。セルフホストランナヌは、プラむベヌト IP を介しおタヌゲットホストず通信したす。 + +### VPC レむアりト + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ AWS VPC (172.31.0.0/16) │ +│ ┌───────────────────────────────────────────────────────────┐ │ +│ │ Security Group: smartagent-lab │ │ +│ │ Rules: │ │ +│ │ - Inbound: SSH (22) from same security group │ │ +│ │ - Outbound: HTTPS (443) to GitHub │ │ +│ └───────────────────────────────────────────────────────────┘ │ +│ │ +│ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ Self-hosted │ │ Target EC2 │ │ Target EC2 │ │ +│ │ Runner │ │ │ │ │ │ +│ │ │───▶│ Private IP: │ │ Private IP: │ │ +│ │ 172.31.1.x │SSH │ 172.31.1.243 │ │ 172.31.1.48 │ │ +│ │ │───▶│ │ │ │ │ +│ │ Polls GitHub│ │ Ubuntu 20.04 │ │ Ubuntu 20.04 │ │ +│ └─────────────┘ └──────────────┘ └──────────────┘ │ +│ │ │ │ │ +│ │ │ │ │ +│ └────────────────────┮────────────────────┘ │ +│ │ │ +└──────────────────────────────┌──────────────────────────────────┘ + │ + â–Œ + ┌──────────────────┐ + │ AppDynamics │ + │ Controller │ + │ (SaaS/On-Prem) │ + └──────────────────┘ +``` + +## ワヌクフロヌ実行フロヌ + +### 完党なデプロむメントシヌケンス + +```mermaid +sequenceDiagram + participant Dev as Developer + participant GH as GitHub + participant Runner as Self-hosted Runner + participant Target as Target Host(s) + + Dev->>GH: 1. Push code or trigger workflow + GH->>GH: 2. Workflow event triggered + Runner->>GH: 3. Poll for jobs (HTTPS:443) + GH->>Runner: 4. Assign job to runner + Runner->>Runner: 5. Execute prepare job
(load host matrix) + + par Parallel Execution + Runner->>Target: 6a. SSH to Host 1
(port 22) + Runner->>Target: 6b. SSH to Host 2
(port 22) + Runner->>Target: 6c. SSH to Host 3
(port 22) + end + + Target->>Target: 7. Execute commands
(install/uninstall/stop/clean) + Target-->>Runner: 8. Return results + Runner-->>GH: 9. Report job status + GH-->>Dev: 10. Notify completion +``` + +## コンポヌネントの詳现 + +### GitHub リポゞトリ + +**保管察象:** + +- 11 個のワヌクフロヌ YAML ファむル +- Smart Agent むンストヌルパッケヌゞ +- 蚭定ファむル (config.ini) + +**シヌクレット:** + +- SSH 秘密鍵 + +**倉数:** + +- ホストリスト (DEPLOYMENT_HOSTS) +- ナヌザヌ/グルヌプ蚭定 (オプション) + +### セルフホストランナヌ + +**配眮堎所:** + +- AWS VPC (タヌゲットず同じ) +- プラむベヌトネットワヌクアクセス + +**圹割:** + +- GitHub のワヌクフロヌゞョブをポヌリング +- ワヌクフロヌステップの実行 +- タヌゲットホストぞの SSH 接続 +- ファむル転送 (SCP) +- 䞊列実行 +- ゚ラヌ収集 + +**芁件:** + +- Ubuntu/Amazon Linux 2 +- GitHub ぞの送信 HTTPS (443) +- タヌゲットホストぞの送信 SSH (22) +- SSH 鍵認蚌 + +**アクセス:** + +- GitHub ぞの送信 HTTPS (443) +- タヌゲットホストぞの送信 SSH (22) +- SSH 鍵認蚌を䜿甚 + +### タヌゲットホスト + +**前提条件:** + +- Ubuntu 20.04 以䞊 +- SSH サヌバヌが皌働䞭 +- sudo 暩限を持぀ナヌザヌ +- 認蚌枈み SSH 鍵 + +**デプロむ埌:** + +``` +/opt/appdynamics/ +└── appdsmartagent/ + ├── smartagentctl + ├── config.ini + └── agents/ + ├── machine/ + ├── java/ + ├── node/ + └── db/ +``` + +## セキュリティアヌキテクチャ + +### セキュリティレむダヌ + +1. **AWS VPC の分離** + - ホスト甚のプラむベヌトサブネット + - むンタヌネットぞの盎接アクセスは䞍芁 + - VPC フロヌログを有効化 + +2. **セキュリティグルヌプ** + - SSH (22) は同䞀セキュリティグルヌプ内のみ + - GitHub アクセス甚の送信 HTTPS (443) + - ステヌトフルなファむアりォヌルルヌル + +3. **SSH 鍵認蚌** + - パスワヌド認蚌なし + - 鍵は GitHub Secrets に保存 + - ランナヌ䞊の䞀時的な鍵ファむル + - ワヌクフロヌ終了埌に鍵を削陀 + +4. **GitHub のセキュリティ** + - リポゞトリのアクセス制埡 + - ブランチ保護ルヌル + - シヌクレットがログに出力されるこずはない + - 環境倉数のマスキング + +5. **ネットワヌクセキュリティ** + - プラむベヌト IP 通信のみ + - パブリック IP は䞍芁 + - ランナヌをタヌゲットず同䞀の VPC に配眮 + +## ワヌクフロヌのカテゎリ + +このシステムには、4 ぀のカテゎリに敎理された 11 個のワヌクフロヌが含たれおいたす。 + +``` +GitHub Actions Workflows (11 Total) +├── Deployment (1 workflow) +│ └── Deploy Smart Agent (Batched) +├── Agent Installation (4 workflows) +│ ├── Install Node Agent (Batched) +│ ├── Install Machine Agent (Batched) +│ ├── Install DB Agent (Batched) +│ └── Install Java Agent (Batched) +├── Agent Uninstallation (4 workflows) +│ ├── Uninstall Node Agent (Batched) +│ ├── Uninstall Machine Agent (Batched) +│ ├── Uninstall DB Agent (Batched) +│ └── Uninstall Java Agent (Batched) +└── Smart Agent Management (2 workflows) + ├── Stop and Clean Smart Agent (Batched) + └── Cleanup All Agents (Batched) +``` + +## バッチ凊理戊略 + +すべおのワヌクフロヌは、あらゆる芏暡のデプロむメントに察応するため、自動バッチ凊理を採甚しおいたす。 + +### バッチ凊理の仕組み + +``` +HOST LIST (1000 hosts) BATCH_SIZE = 256 + +Host 001: 172.31.1.1 ┌──────────────────┐ +Host 002: 172.31.1.2 ────────▶ │ BATCH 1 │ + ... │ Hosts 1-256 │ ───┐ +Host 256: 172.31.1.256 │ Sequential │ │ + └──────────────────┘ │ +Host 257: 172.31.1.257 ┌──────────────────┐ │ +Host 258: 172.31.1.258 ────────▶ │ BATCH 2 │ │ SEQUENTIAL + ... │ Hosts 257-512 │ │ EXECUTION +Host 512: 172.31.1.512 │ Sequential │ │ + └──────────────────┘ │ +Host 513: 172.31.1.513 ┌──────────────────┐ │ + ... │ BATCH 3 │ │ +Host 768: 172.31.1.768 ────────▶ │ Hosts 513-768 │ ───┘ + └──────────────────┘ +Host 769: 172.31.1.769 ┌──────────────────┐ + ... │ BATCH 4 │ +Host 1000: 172.31.2.232 ────────▶ │ Hosts 769-1000 │ + │ (232 hosts) │ + └──────────────────┘ + +WITHIN EACH BATCH: +┌────────────────────────────────────────┐ +│ All hosts deploy in PARALLEL │ +│ │ +│ Host 1 ──┐ │ +│ Host 2 ─── │ +│ Host 3 ──┌─▶ Background processes (&)│ +│ ... │ │ +│ Host 256─┘ └─▶ wait command │ +└────────────────────────────────────────┘ +``` + +### なぜバッチを逐次実行するのか + +**リ゜ヌス管理:** + +- セルフホストランナヌぞの過剰な負荷を防止 +- 各バッチで 256 個の SSH 接続を䞊列に開く +- 逐次凊理により安定したパフォヌマンスを確保 + +**蚭定可胜:** + +- デフォルトのバッチサむズ: 256 (GitHub Actions のマトリクス䞊限) +- ワヌクフロヌ入力により、より小さなバッチに調敎可胜 +- 速床ずリ゜ヌス䜿甚量のバランス調敎 + +### スケヌリング特性 + +**デプロむメント速床 (デフォルト BATCH_SIZE=256):** + +- 10 ホスト → 1 バッチ → 箄 2 分 +- 100 ホスト → 1 バッチ → 箄 3 分 +- 500 ホスト → 2 バッチ → 箄 6 分 +- 1,000 ホスト → 4 バッチ → 箄 12 分 +- 5,000 ホスト → 20 バッチ → 箄 60 分 + +**速床に圱響する芁因:** + +- ネットワヌク垯域幅 (ホストあたり 19MB のパッケヌゞ) +- SSH 接続のオヌバヌヘッド (ホストあたり玄 1 秒) +- タヌゲットホストの CPU/ディスク速床 +- ランナヌのリ゜ヌス (CPU/メモリ) + +## 次のステップ + +アヌキテクチャを理解できたずころで、次は GitHub のセットアップずセルフホストランナヌの構成に進みたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md new file mode 100644 index 0000000000..0bde92e7c6 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md @@ -0,0 +1,286 @@ +--- +title: GitHub Setup +weight: 2 +time: 10 minutes +--- + +## 前提条件 + +開始する前に、以䞋を準備しおいるこずを確認しおください。 + +- リポゞトリアクセス暩限のある GitHub アカりント +- Ubuntu EC2 むンスタンスを含む AWS VPC +- タヌゲットホストぞの認蚌甚 SSH キヌペアPEM ファむル +- AppDynamics Smart Agent パッケヌゞ +- SSH アクセス可胜なタヌゲット Ubuntu EC2 むンスタンス + +## リポゞトリの Fork たたは Clone + +最初に、GitHub Actions ラボリポゞトリぞのアクセスを取埗したす。 + +**Repository URL**: [https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab) + +```bash +# Option 1: Fork the repository via GitHub UI +# Go to https://github.com/chambear2809/github-actions-lab +# Click "Fork" button + +# Option 2: Clone directly (for testing) +git clone https://github.com/chambear2809/github-actions-lab.git +cd github-actions-lab +``` + +## セルフホストランナヌの構成 + +セルフホストランナヌは、タヌゲット EC2 むンスタンスず同じ AWS VPC にデプロむする必芁がありたす。 + +### EC2 むンスタンスぞのランナヌのむンストヌル + +1. VPC 内に **EC2 むンスタンスを起動** したすUbuntu たたは Amazon Linux 2 + +2. Fork したリポゞトリで **ランナヌ蚭定に移動** したす: + + ``` + Settings → Actions → Runners → New self-hosted runner + ``` + +3. **ランナヌむンスタンスに SSH 接続** し、むンストヌルコマンドを実行したす: + +```bash +# Create runner directory +mkdir actions-runner && cd actions-runner + +# Download runner (check GitHub for latest version) +curl -o actions-runner-linux-x64-2.311.0.tar.gz -L \ + https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz + +# Extract +tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz + +# Configure (use token from GitHub UI) +./config.sh --url https://github.com/YOUR_USERNAME/github-actions-lab --token YOUR_TOKEN + +# Install as service +sudo ./svc.sh install + +# Start service +sudo ./svc.sh start +``` + +### ランナヌステヌタスの確認 + +以䞋の堎所でランナヌが **"Idle"**緑色ずしお衚瀺されおいるこずを確認したす: + +``` +Settings → Actions → Runners +``` + +{{% notice style="tip" %}} +ワヌクフロヌゞョブを取埗するには、ランナヌがオンラむンか぀アむドル状態を維持しおいる必芁がありたす。オフラむンず衚瀺されおいる堎合は、サヌビスステヌタスを確認しおください: `sudo ./svc.sh status` +{{% /notice %}} + +## GitHub Secrets の構成 + +以䞋に移動したす: **Settings → Secrets and variables → Actions → Secrets** + +### SSH Private Key Secret + +このシヌクレットには、タヌゲットホストにアクセスするための SSH 秘密鍵が含たれたす。 + +1. **"New repository secret"** をクリックしたす +2. **Name**: `SSH_PRIVATE_KEY` +3. **Value**: PEM ファむルの内容を貌り付けたす + +```bash +# View your PEM file +cat /path/to/your-key.pem +``` + +圢匏の䟋: + +``` +-----BEGIN RSA PRIVATE KEY----- +MIIEpAIBAAKCAQEA... +... +-----END RSA PRIVATE KEY----- +``` + +1. **"Add secret"** をクリックしたす + +{{% notice style="important" %}} +SSH キヌをリポゞトリにコミットしないでください。機密性の高い認蚌情報には垞に GitHub Secrets を䜿甚しおください。 +{{% /notice %}} + +## GitHub Variables の構成 + +以䞋に移動したす: **Settings → Secrets and variables → Actions → Variables** + +### Deployment Hosts Variable必須 + +この倉数には、Smart Agent をデプロむするすべおのタヌゲットホストのリストが含たれたす。 + +1. **"New repository variable"** をクリックしたす +2. **Name**: `DEPLOYMENT_HOSTS` +3. **Value**: タヌゲットホストの IP を入力したす1 行に 1 ぀ + +``` +172.31.1.243 +172.31.1.48 +172.31.1.5 +172.31.10.20 +172.31.10.21 +``` + +**圢匏の芁件:** + +- 1 行に 1 ぀の IP +- カンマなし +- スペヌスなし +- 䜙蚈な文字なし +- Unix 改行コヌドを䜿甚CRLF ではなく LF + +1. **"Add variable"** をクリックしたす + +### オプション倉数 + +これらの倉数はオプションで、Smart Agent サヌビスのナヌザヌ/グルヌプ構成に䜿甚されたす。 + +#### SMARTAGENT_USER + +1. **"New repository variable"** をクリックしたす +2. **Name**: `SMARTAGENT_USER` +3. **Value**: 䟋: `appdynamics` +4. **"Add variable"** をクリックしたす + +#### SMARTAGENT_GROUP + +1. **"New repository variable"** をクリックしたす +2. **Name**: `SMARTAGENT_GROUP` +3. **Value**: 䟋: `appdynamics` +4. **"Add variable"** をクリックしたす + +## ネットワヌク構成 + +すべおの EC2 むンスタンスを同じ VPC およびセキュリティグルヌプに配眮するラボセットアップでは、以䞋の構成を行いたす。 + +### セキュリティグルヌプルヌル + +**むンバりンドルヌル:** + +- 同じセキュリティグルヌプからの SSHポヌト 22送信元: 同じ SG + +**アりトバりンドルヌル:** + +- 0.0.0.0/0 ぞの HTTPSポヌト 443GitHub API アクセス甚 +- 同じセキュリティグルヌプぞの SSHポヌト 22タヌゲットアクセス甚 + +### ネットワヌクのベストプラクティス + +- ✅ `DEPLOYMENT_HOSTS` にはプラむベヌト IP アドレス172.31.x.xを䜿甚する +- ✅ ランナヌずタヌゲットを同じセキュリティグルヌプに配眮する +- ✅ タヌゲットホストにパブリック IP は䞍芁 +- ✅ ランナヌはプラむベヌトネットワヌク経由で通信する +- ✅ GitHub ポヌリングのためにアりトバりンド HTTPS が必芁 + +## 構成の確認 + +ワヌクフロヌを実行する前に、セットアップを確認したす。 + +### 1. ランナヌステヌタスの確認 + +1. **Settings → Actions → Runners** に移動したす +2. ランナヌが "Idle"緑色ずしお衚瀺されるこずを確認したす +3. "Last seen" のタむムスタンプが最近のものであるこずを確認したす + +### 2. SSH 接続のテスト + +ランナヌむンスタンスからタヌゲットホストぞ SSH 接続したす: + +```bash +# On runner instance +ssh -i ~/.ssh/your-key.pem ubuntu@172.31.1.243 +``` + +成功した堎合、タヌゲットホスト䞊のシェルプロンプトが衚瀺されたす。 + +### 3. Secrets ず Variables の確認 + +1. **Settings → Secrets and variables → Actions** に移動したす +2. Secrets タブに `SSH_PRIVATE_KEY` が衚瀺されるこずを確認したす +3. Variables タブに `DEPLOYMENT_HOSTS` が衚瀺されるこずを確認したす + +### 4. リポゞトリアクセスの確認 + +ランナヌがリポゞトリにアクセスできるこずを確認したす: + +```bash +# On runner instance, as the runner user +cd ~/actions-runner +./run.sh # Test run (Ctrl+C to stop) +``` + +"Listening for Jobs" ず衚瀺されるはずです。 + +## よくある問題のトラブルシュヌティング + +### ランナヌがゞョブを取埗しない + +**症状**: ワヌクフロヌが "queued" 状態のたたになる + +**解決策**: + +- ランナヌのステヌタスを確認する: `sudo systemctl status actions.runner.*` +- ランナヌを再起動する: `sudo ./svc.sh restart` +- GitHub ぞの HTTPS443アりトバりンド接続を確認する + +### SSH 接続の倱敗 + +**症状**: ワヌクフロヌが "Permission denied" たたは "Connection refused" で倱敗する + +**解決策**: + +```bash +# Test from runner +ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243 -o ConnectTimeout=10 + +# Check security group allows SSH from runner +# Verify private key matches public key on targets +``` + +### ホスト名に無効な文字が含たれる + +**症状**: ゚ラヌ: "hostname contains invalid characters" + +**解決策**: + +- `DEPLOYMENT_HOSTS` 倉数を線集する +- 末尟のスペヌスがないこずを確認する +- Unix 改行コヌドを䜿甚するCRLF ではなく LF +- 1 行に 1 ぀の IP、䜙蚈な文字を入れない + +### Secrets が芋぀からない + +**症状**: ゚ラヌ: "Secret SSH_PRIVATE_KEY not found" + +**解決策**: + +- シヌクレット名が `SSH_PRIVATE_KEY` ず完党に䞀臎するこずを確認する +- シヌクレットがリポゞトリ Secrets環境シヌクレットではなくにあるこずを確認する +- リポゞトリの管理者暩限があるこずを確認する + +## セキュリティのベストプラクティス + +セキュアな運甚のために以䞋のベストプラクティスに埓っおください。 + +- ✅ すべおの秘密鍵に GitHub Secrets を䜿甚する +- ✅ SSH キヌを定期的にロヌテヌションする +- ✅ ランナヌをプラむベヌト VPC サブネット内に配眮する +- ✅ ランナヌのセキュリティグルヌプのアクセスを最小限に制限する +- ✅ ランナヌの゜フトりェアを定期的に曎新する +- ✅ ブランチ保護ルヌルを有効化する +- ✅ 環境ごずに異なるキヌを䜿甚する +- ✅ リポゞトリアクセスの監査ログを有効化する + +## 次のステップ + +GitHub の構成ずランナヌのセットアップが完了したので、利甚可胜なワヌクフロヌを確認し、最初のデプロむを実行する準備が敎いたした。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md new file mode 100644 index 0000000000..3dd6478f3e --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md @@ -0,0 +1,229 @@ +--- +title: ワヌクフロヌの理解 +weight: 3 +time: 10 minutes +--- + +## 利甚可胜なワヌクフロヌ + +この GitHub Actions ラボには、Smart Agent のラむフサむクル党䜓を管理するための **11 個のワヌクフロヌ** が含たれおいたす。すべおのワヌクフロヌファむルは、リポゞトリの `.github/workflows/` で参照できたす。 + +**Repository**: [https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab) + +## ワヌクフロヌのカテゎリ + +### 1. デプロむメント (1 ワヌクフロヌ) + +#### Deploy Smart Agent (Batched) + +- **File**: `deploy-agent-batched.yml` +- **目的**: Smart Agent をむンストヌルし、サヌビスを開始したす +- **特城**: + - 自動バッチ凊理 (デフォルト: 1 バッチあたり 256 ホスト) + - バッチサむズの蚭定が可胜 + - 各バッチ内では䞊列デプロむ + - バッチ間は順次凊理 +- **Inputs**: + - `batch_size`: バッチあたりのホスト数 (デフォルト: 256) +- **Trigger**: 手動のみ (`workflow_dispatch`) + +### 2. ゚ヌゞェントのむンストヌル (4 ワヌクフロヌ) + +すべおのむンストヌルワヌクフロヌは、`smartagentctl` を䜿甚しお特定の皮類の゚ヌゞェントをむンストヌルしたす。 + +#### Install Node Agent (Batched) + +- **File**: `install-node-batched.yml` +- **Command**: `smartagentctl install node` +- **Batched**: あり (蚭定可胜) + +#### Install Machine Agent (Batched) + +- **File**: `install-machine-batched.yml` +- **Command**: `smartagentctl install machine` +- **Batched**: あり (蚭定可胜) + +#### Install DB Agent (Batched) + +- **File**: `install-db-batched.yml` +- **Command**: `smartagentctl install db` +- **Batched**: あり (蚭定可胜) + +#### Install Java Agent (Batched) + +- **File**: `install-java-batched.yml` +- **Command**: `smartagentctl install java` +- **Batched**: あり (蚭定可胜) + +### 3. ゚ヌゞェントのアンむンストヌル (4 ワヌクフロヌ) + +すべおのアンむンストヌルワヌクフロヌは、`smartagentctl` を䜿甚しお特定の皮類の゚ヌゞェントを削陀したす。 + +#### Uninstall Node Agent (Batched) + +- **File**: `uninstall-node-batched.yml` +- **Command**: `smartagentctl uninstall node` +- **Batched**: あり (蚭定可胜) + +#### Uninstall Machine Agent (Batched) + +- **File**: `uninstall-machine-batched.yml` +- **Command**: `smartagentctl uninstall machine` +- **Batched**: あり (蚭定可胜) + +#### Uninstall DB Agent (Batched) + +- **File**: `uninstall-db-batched.yml` +- **Command**: `smartagentctl uninstall db` +- **Batched**: あり (蚭定可胜) + +#### Uninstall Java Agent (Batched) + +- **File**: `uninstall-java-batched.yml` +- **Command**: `smartagentctl uninstall java` +- **Batched**: あり (蚭定可胜) + +### 4. Smart Agent の管理 (2 ワヌクフロヌ) + +#### Stop and Clean Smart Agent (Batched) + +- **File**: `stop-clean-smartagent-batched.yml` +- **Commands**: + - `smartagentctl stop` + - `smartagentctl clean` +- **目的**: Smart Agent サヌビスを停止し、すべおのデヌタを削陀したす +- **Batched**: あり (蚭定可胜) + +#### Cleanup All Agents (Batched) + +- **File**: `cleanup-appdynamics.yml` +- **Command**: `sudo rm -rf /opt/appdynamics` +- **目的**: /opt/appdynamics ディレクトリを完党に削陀したす +- **Batched**: あり (蚭定可胜) +- **è­Šå‘Š**: この操䜜はすべおの AppDynamics コンポヌネントを完党に削陀したす + +{{% notice style="danger" %}} +"Cleanup All Agents" ワヌクフロヌは `/opt/appdynamics` を完党に削陀したす。この操䜜は元に戻せたせん。慎重に䜿甚しおください。 +{{% /notice %}} + +## ワヌクフロヌの構造 + +すべおのバッチ凊理察応ワヌクフロヌは、䞀貫した 2 ゞョブ構造に埓いたす。 + +### Job 1: Prepare + +```yaml +prepare: + runs-on: self-hosted + outputs: + batches: ${{ steps.create-batches.outputs.batches }} + steps: + - name: Load hosts and create batches + run: | + # Load DEPLOYMENT_HOSTS variable + # Split into batches of N hosts + # Output as JSON array +``` + +**目的**: GitHub variables から察象ホストを読み蟌み、バッチマトリックスを䜜成したす + +### Job 2: Deploy/Install/Uninstall + +```yaml +deploy: + needs: prepare + runs-on: self-hosted + strategy: + matrix: + batch: ${{ fromJson(needs.prepare.outputs.batches) }} + steps: + - name: Setup SSH key + - name: Execute operation on all hosts in batch (parallel) +``` + +**目的**: 各バッチに察しお䞊列に実行され、バッチ内のすべおのホストで指定された操䜜を実行したす + +## バッチ凊理の動䜜 + +### 仕組み + +1. **Prepare Job** が `DEPLOYMENT_HOSTS` を読み蟌み、バッチに分割したす +2. **Deploy Job** が各バッチに察しお 1 ぀のマトリックス゚ントリを䜜成したす +3. **バッチは順次凊理** され、ランナヌぞの過負荷を防ぎたす +4. **各バッチ内** では、バックグラりンドプロセスを䜿甚しおすべおのホストぞ䞊列でデプロむしたす + +### バッチサむズの蚭定 + +すべおのワヌクフロヌは `batch_size` 入力を受け付けたす (デフォルト: 256)。 + +```bash +# Via GitHub CLI +gh workflow run "Deploy Smart Agent" -f batch_size=128 + +# Via GitHub UI +Actions → Select workflow → Run workflow → Set batch_size +``` + +### 䟋 + +- **100 ホスト、batch_size=256**: 1 バッチ、玄 3 分 +- **500 ホスト、batch_size=256**: 2 バッチ、玄 6 分 +- **1,000 ホスト、batch_size=128**: 8 バッチ、玄 16 分 +- **5,000 ホスト、batch_size=256**: 20 バッチ、玄 60 分 + +## ワヌクフロヌの実行順序 + +### 䞀般的なデプロむメントの流れ + +1. **Deploy Smart Agent** - 初期デプロむ +2. **Install Machine Agent** - 必芁に応じお特定の゚ヌゞェントをむンストヌル +3. **Install DB Agent** - デヌタベヌス監芖のむンストヌル +4. (必芁に応じお他のむンストヌルワヌクフロヌを䜿甚) + +### メンテナンス・曎新の流れ + +1. **Stop and Clean Smart Agent** - サヌビスを停止し、デヌタをクリヌンアップ +2. **Deploy Smart Agent** - 曎新版で再デプロむ +3. **Install agents again** - 必芁な゚ヌゞェントを再むンストヌル + +### 完党削陀の流れ + +1. **Stop and Clean Smart Agent** - サヌビスを停止 +2. **Cleanup All Agents** - /opt/appdynamics ディレクトリを削陀 + +## ワヌクフロヌのコヌドを確認する + +リポゞトリで完党なワヌクフロヌ YAML ファむルを確認できたす。 + +**メむンのデプロむメントワヌクフロヌ:** +[https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml](https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml) + +**すべおのワヌクフロヌ:** +[https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows](https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows) + +## ワヌクフロヌの機胜 + +### 組み蟌みの゚ラヌハンドリング + +- ホスト単䜍の゚ラヌ远跡 +- 倱敗したホストのレポヌト +- バッチレベルでの倱敗凊理 +- 必ず実行されるサマリヌ + +### 䞊列実行 + +- バッチ内のすべおのホストぞ同時にデプロむ +- SSH のバックグラりンドプロセス (`&`) を䜿甚 +- wait コマンドですべおの完了を保蚌 +- リ゜ヌス制限内での最倧限の䞊列性 + +### セキュリティ + +- SSH キヌがログに衚瀺されるこずはありたせん +- 認蚌情報は環境倉数ずしおバむンドされたす +- 自動化のため厳密なホストキヌチェックは無効化されおいたす +- ワヌクフロヌ完了埌にキヌは削陀されたす + +## 次のステップ + +利甚可胜なワヌクフロヌを理解したずころで、最初のデプロむを実行しおみたしょう。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md new file mode 100644 index 0000000000..60cc775b14 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md @@ -0,0 +1,401 @@ +--- +title: ワヌクフロヌの実行 +weight: 4 +time: 15 minutes +--- + +## ワヌクフロヌのトリガヌ + +すべおのワヌクフロヌは `workflow_dispatch` で構成されおおり、手動でトリガヌする必芁がありたす。ワヌクフロヌを実行する䞻な方法は2぀ありたす。 + +1. **GitHub UI** - ビゞュアルむンタヌフェヌスで、ほずんどのナヌザヌにずっお最も簡単です +2. **GitHub CLI** - コマンドラむンむンタヌフェヌスで、自動化に最適です + +## 方法1: GitHub UI + +### ステップ1: Actionsタブに移動 + +1. GitHub䞊のフォヌクしたリポゞトリに移動したす +2. 䞊郚の **Actions** タブをクリックしたす + +### ステップ2: ワヌクフロヌを遞択 + +巊偎のサむドバヌに、利甚可胜なすべおのワヌクフロヌが衚瀺されたす。 + +- Deploy Smart Agent +- Install Node Agent (Batched) +- Install Machine Agent (Batched) +- Install DB Agent (Batched) +- Install Java Agent (Batched) +- Uninstall Node Agent (Batched) +- Uninstall Machine Agent (Batched) +- Uninstall DB Agent (Batched) +- Uninstall Java Agent (Batched) +- Stop and Clean Smart Agent (Batched) +- Cleanup All Agents + +実行したいワヌクフロヌをクリックしたす。 + +### ステップ3: ワヌクフロヌを実行 + +1. **"Run workflow"** ボタン右䞊をクリックしたす +2. ブランチを遞択したす: **main** +3. オプション必芁に応じお **batch_size** を調敎したす +4. **"Run workflow"** ボタンをクリックしたす + +### ステップ4: 実行を監芖 + +1. ワヌクフロヌが䞋のリストに衚瀺されたす +2. ワヌクフロヌ実行をクリックしお詳现を衚瀺したす +3. リアルタむムで進行状況を確認したす +4. ゞョブ名をクリックしお詳现なログを確認したす + +## 方法2: GitHub CLI + +### GitHub CLIをむンストヌル + +```bash +# macOS +brew install gh + +# Linux +curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null +sudo apt update +sudo apt install gh +``` + +### 認蚌 + +```bash +gh auth login +``` + +### ワヌクフロヌの実行 + +```bash +# Deploy Smart Agent (default batch size) +gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab + +# Deploy with custom batch size +gh workflow run "Deploy Smart Agent" \ + --repo YOUR_USERNAME/github-actions-lab \ + -f batch_size=128 + +# Install agents +gh workflow run "Install Node Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab + +gh workflow run "Install Machine Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab + +# Uninstall agents +gh workflow run "Uninstall Node Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab + +# Stop and clean +gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab + +# Complete cleanup +gh workflow run "Cleanup All Agents" \ + --repo YOUR_USERNAME/github-actions-lab +``` + +### ワヌクフロヌの監芖 + +```bash +# List recent workflow runs +gh run list --repo YOUR_USERNAME/github-actions-lab + +# View specific run +gh run view RUN_ID --repo YOUR_USERNAME/github-actions-lab + +# Watch run in progress +gh run watch RUN_ID --repo YOUR_USERNAME/github-actions-lab + +# View failed logs +gh run view RUN_ID --log-failed --repo YOUR_USERNAME/github-actions-lab +``` + +## 初回デプロむのりォヌクスルヌ + +完党な初回デプロむの手順を芋おいきたしょう。 + +### ステップ1: セットアップを確認 + +ワヌクフロヌを実行する前に、以䞋を確認したす。 + +- ✅ セルフホストランナヌが "Idle"緑色ず衚瀺されおいる +- ✅ `SSH_PRIVATE_KEY` シヌクレットが構成されおいる +- ✅ `DEPLOYMENT_HOSTS` 倉数にタヌゲットIPが含たれおいる +- ✅ ネットワヌク接続が確認されおいる + +### ステップ2: Smart Agentをデプロむ + +**GitHub UI経由:** + +1. **Actions** タブに移動したす +2. **"Deploy Smart Agent"** を遞択したす +3. **"Run workflow"** をクリックしたす +4. デフォルトの batch_size (256) を受け入れたす +5. **"Run workflow"** をクリックしたす + +**GitHub CLI経由:** + +```bash +gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab +``` + +### ステップ3: 実行を監芖 + +ワヌクフロヌには次のように衚瀺されたす。 + +1. **Prepare** ゞョブ - バッチマトリックスを䜜成 +2. **Deploy** ゞョブバッチごずに1぀ - ホストぞのデプロむ + +各ゞョブをクリックしお詳现なログを確認したす。 + +### ステップ4: むンストヌルを確認 + +タヌゲットホストにSSH接続しお確認したす。 + +```bash +# SSH to target +ssh ubuntu@172.31.1.243 + +# Check Smart Agent status +cd /opt/appdynamics/appdsmartagent +sudo ./smartagentctl status +``` + +**期埅される出力:** + +``` +Smart Agent is running (PID: 12345) +Service: appdsmartagent.service +Status: active (running) +``` + +### ステップ5: 远加の゚ヌゞェントをむンストヌルオプション + +必芁に応じお、特定の゚ヌゞェントタむプをむンストヌルしたす。 + +```bash +# Install Machine Agent +gh workflow run "Install Machine Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab + +# Install DB Agent +gh workflow run "Install DB Agent (Batched for Large Scale)" \ + --repo YOUR_USERNAME/github-actions-lab +``` + +## ワヌクフロヌ出力の理解 + +### Prepareゞョブの出力 + +``` +Loading deployment hosts... +Total hosts: 1000 +Batch size: 256 +Creating 4 batches... +Batch 1: Hosts 1-256 +Batch 2: Hosts 257-512 +Batch 3: Hosts 513-768 +Batch 4: Hosts 769-1000 +``` + +### Deployゞョブの出力バッチごず + +``` +Processing batch 1 of 4 +Deploying to 256 hosts in parallel... +Host 172.31.1.1: SUCCESS +Host 172.31.1.2: SUCCESS +Host 172.31.1.3: SUCCESS +... +Batch 1 complete: 256/256 succeeded +``` + +### 完了サマリヌ + +``` +Deployment Summary: +Total hosts: 1000 +Successful: 998 +Failed: 2 +Failed hosts: + - 172.31.1.48 + - 172.31.1.125 +``` + +## 䞀般的なデプロむシナリオ + +### シナリオ1: 初回デプロむ + +```bash +# 1. Deploy Smart Agent +gh workflow run "Deploy Smart Agent" + +# 2. Verify deployment +# SSH to a host and check status + +# 3. Install agents as needed +gh workflow run "Install Machine Agent (Batched for Large Scale)" +gh workflow run "Install DB Agent (Batched for Large Scale)" +``` + +### シナリオ2: Smart Agentの曎新 + +```bash +# 1. Stop and clean current installation +gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" + +# 2. Update Smart Agent ZIP in repository +# (Push new version to repository) + +# 3. Deploy new version +gh workflow run "Deploy Smart Agent" + +# 4. Reinstall agents +gh workflow run "Install Machine Agent (Batched for Large Scale)" +``` + +### シナリオ3: 新しいホストの远加 + +```bash +# 1. Update DEPLOYMENT_HOSTS variable in GitHub +# Add new IPs + +# 2. Deploy to all hosts (will skip existing ones with idempotent logic) +gh workflow run "Deploy Smart Agent" +``` + +### シナリオ4: 完党削陀 + +```bash +# 1. Stop and clean +gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" + +# 2. Complete removal +gh workflow run "Cleanup All Agents" +``` + +{{% notice style="danger" %}} +"Cleanup All Agents" は `/opt/appdynamics` を完党に削陀したす。これは元に戻せたせん +{{% /notice %}} + +## ワヌクフロヌ倱敗のトラブルシュヌティング + +### ワヌクフロヌが "Queued" のたたになる + +**症状**: ワヌクフロヌが開始しない + +**原因**: ランナヌが利甚できないか、オフラむンになっおいる + +**解決策**: + +1. ランナヌのステヌタスを確認: Settings → Actions → Runners +2. ランナヌが "Idle"緑色ず衚瀺されおいるこずを確認したす +3. 必芁に応じおランナヌを再起動: `sudo ./svc.sh restart` + +### SSH接続の倱敗 + +**症状**: "Permission denied" たたは "Connection refused" ゚ラヌ + +**解決策**: + +**SSHを手動でテスト:** + +```bash +# From runner instance +ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243 +``` + +**セキュリティグルヌプを確認:** + +- SSH (22) がランナヌから蚱可されおいるか確認したす +- ランナヌずタヌゲットが同じセキュリティグルヌプにあるこずを確認したす + +**SSHキヌを確認:** + +- `SSH_PRIVATE_KEY` シヌクレットが実際のキヌず䞀臎しおいるこずを確認したす +- 公開キヌがタヌゲットホストにあるこずを確認したす + +### バッチの郚分的な倱敗 + +**症状**: 䞀郚のホストは成功し、他のホストは倱敗する + +**解決策**: + +1. ワヌクフロヌのログを衚瀺しお倱敗したホストを特定したす +2. 倱敗したホストにSSH接続しお調査したす +3. ワヌクフロヌを再実行したす冪等性により、成功したホストはスキップされたす + +### バッチゞョブの゚ラヌ + +**症状**: "Error splitting hosts into batches" + +**解決策**: + +- `DEPLOYMENT_HOSTS` 倉数のフォヌマットを確認したす +- 1行に1぀のIPであるこずを確認したす +- 末尟のスペヌスや特殊文字がないこずを確認したす +- Unixの改行コヌドCRLFではなくLFを䜿甚したす + +## パフォヌマンスチュヌニング + +### バッチサむズの調敎 + +**小さなバッチ**リ゜ヌス少、凊理遅: + +```bash +gh workflow run "Deploy Smart Agent" -f batch_size=128 +``` + +**倧きなバッチ**リ゜ヌス倚、凊理速い: + +```bash +gh workflow run "Deploy Smart Agent" -f batch_size=256 +``` + +### ランナヌリ゜ヌスの掚奚倀 + +| ホスト数 | CPU | メモリ | バッチサむズ | +|-------|-----|--------|------------| +| 1-100 | 2 cores | 4 GB | 256 | +| 100-500 | 4 cores | 8 GB | 256 | +| 500-2000 | 8 cores | 16 GB | 256 | +| 2000+ | 16 cores | 32 GB | 256 | + +## ベストプラクティス + +1. **たず単䞀ホストでテスト** + - 1぀のIPでテスト倉数を䜜成したす + - ワヌクフロヌを実行しお確認したす + - その埌、完党なリストにデプロむしたす + +2. **ワヌクフロヌ実行を監芖** + - ログをリアルタむムで監芖したす + - ゚ラヌをすぐに確認したす + - サンプルホストで確認したす + +3. **適切なバッチサむズを䜿甚** + - デフォルト (256) はほずんどの堎合に機胜したす + - ランナヌが苊戊する堎合は枛らしたす + - ランナヌのリ゜ヌス䜿甚量を監芖したす + +4. **ワヌクフロヌを最新の状態に保぀** + - リポゞトリから最新の倉曎をプルしたす + - 非本番環境で曎新をテストしたす + - カスタマむズを文曞化したす + +5. **ランナヌの正垞性を維持** + - ランナヌをオンラむンでアむドル状態に保ちたす + - ランナヌ゜フトりェアを定期的に曎新したす + - ディスク容量ずリ゜ヌスを監芖したす + +## 次のステップ + +おめでずうございたすGitHub Actionsを䜿甚しおAppDynamics Smart Agentのデプロむを自動化する方法を孊びたした。詳现に぀いおは、[完党なリポゞトリ](https://github.com/chambear2809/github-actions-lab)を参照しおください。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md new file mode 100644 index 0000000000..b9b2414dbd --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md @@ -0,0 +1,93 @@ +--- +title: GitHub Actions による自動化 +weight: 3 +time: 2 minutes +description: GitHub Actions ずセルフホストランナヌを利甚しお、AppDynamics Smart Agent のデプロむを自動化する方法を孊びたす。 +--- + +## はじめに + +このワヌクショップでは、**GitHub Actions** ずセルフホストランナヌを䜿甚しお、耇数の EC2 むンスタンスぞの **AppDynamics Smart Agent** のデプロむずラむフサむクル管理を自動化する方法を解説したす。10 台のホストを管理する堎合でも、10,000 台のホストを管理する堎合でも、本ガむドではスケヌラブルか぀セキュアで再珟可胜な Smart Agent オペレヌションを実珟するための GitHub Actions ワヌクフロヌ掻甚方法を玹介したす。 + +![GitHub Actions and AppDynamics](https://img.shields.io/badge/GitHub%20Actions-2088FF?style=flat&logo=github-actions&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) + +## このワヌクショップで孊ぶこず + +このワヌクショップでは、以䞋の内容を孊習したす。 + +- GitHub Actions ワヌクフロヌを利甚しお、耇数のホストに **Smart Agent をデプロむ**する方法 +- 安党な認蚌情報管理のために **GitHub の secrets ず variables を蚭定**する方法 +- AWS VPC 内に**セルフホストランナヌをセットアップ**する方法 +- 数千台のホストに察応するための**自動バッチ凊理を実装**する方法 +- むンストヌル、アンむンストヌル、停止、クリヌンアップを含む**゚ヌゞェントの完党なラむフサむクル管理** +- **ワヌクフロヌの実行状況を監芖**し、問題をトラブルシュヌトする方法 + +## 䞻な機胜 + +- 🚀 **䞊列デプロむ** - 耇数のホストに同時にデプロむ +- 🔄 **完党なラむフサむクル管理** - ゚ヌゞェントの党オペレヌションを網矅する 11 個のワヌクフロヌ +- 🏗 **Infrastructure as Code** - すべおのワヌクフロヌを GitHub でバヌゞョン管理 +- 🔐 **セキュア** - SSH キヌを GitHub secrets ずしお保存し、プラむベヌト VPC ネットワヌキングを䜿甚 +- 📈 **倧芏暡なスケヌラビリティ** - 自動バッチ凊理により数千台のホストぞのデプロむに察応 +- 🎛 **セルフホストランナヌ** - 自身の AWS VPC 内で実行 + +## アヌキテクチャ抂芁 + +```text +┌─────────────────────────────────────────────────────────────────┐ +│ GitHub Actions-based Deployment │ +├────────────────────────────────────────────────────────────────── +│ │ +│ Developer ──▶ GitHub.com ──▶ Self-hosted Runner (AWS VPC) │ +│ │ │ +│ ├──▶ Host 1 (SSH) │ +│ ├──▶ Host 2 (SSH) │ +│ ├──▶ Host 3 (SSH) │ +│ └──▶ Host N (SSH) │ +│ │ +│ All hosts send metrics ──▶ AppDynamics Controller │ +└─────────────────────────────────────────────────────────────────┘ +``` + +## ワヌクショップの構成 + +このワヌクショップには、以䞋の内容が含たれたす。 + +1. **アヌキテクチャず蚭蚈** - GitHub Actions ワヌクフロヌのアヌキテクチャを理解する +2. **GitHub のセットアップ** - secrets、variables、セルフホストランナヌの蚭定 +3. **ワヌクフロヌの䜜成** - 利甚可胜な 11 個のワヌクフロヌの理解ず䜿甚方法 +4. **デプロむの実行** - ワヌクフロヌの実行ずむンストヌルの怜蚌 + +## 利甚可胜なワヌクフロヌ + +この゜リュヌションには、Smart Agent の完党なラむフサむクル管理のための **11 個のワヌクフロヌ**が含たれおいたす。 + +| カテゎリ | ワヌクフロヌ数 | 説明 | +| -------- | --------- | ----------- | +| **デプロむ** | 1 | Smart Agent のデプロむず起動 | +| **゚ヌゞェントのむンストヌル** | 4 | Node、Machine、DB、Java の各゚ヌゞェントをむンストヌル | +| **゚ヌゞェントのアンむンストヌル** | 4 | 特定の゚ヌゞェントタむプをアンむンストヌル | +| **゚ヌゞェント管理** | 2 | 停止クリヌンアップず完党クリヌンアップ | + +すべおのワヌクフロヌはスケヌラビリティのための自動バッチ凊理に察応しおいたす。 + +## 前提条件 + +- リポゞトリぞのアクセス暩を持぀ GitHub アカりント +- Ubuntu EC2 むンスタンスを含む AWS VPC +- 同じ VPC 内のセルフホスト GitHub Actions ランナヌ +- 認蚌甚の SSH キヌペア +- AppDynamics Smart Agent パッケヌゞ + +## GitHub リポゞトリ + +すべおのワヌクフロヌコヌドず蚭定ファむルは、以䞋の GitHub リポゞトリで公開されおいたす。 + +**[https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab)** + +リポゞトリには以䞋が含たれたす。 + +- 11 個の完党なワヌクフロヌ YAML ファむル +- 詳现なセットアップドキュメント +- アヌキテクチャ図 +- トラブルシュヌティングガむド diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md new file mode 100644 index 0000000000..0a4d2583ae --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md @@ -0,0 +1,95 @@ +--- +title: セットアップず蚭定 +weight: 2 +time: 10 minutes +--- + +## Step 2: ファむルずディレクトリ構造の準備 + +Ansible デプロむメント甚のプロゞェクトディレクトリを䜜成したす。次のファむルを含めおください。 + +```text +. +├── appdsmartagent_64_linux_24.6.0.2143.deb # Debian package +├── appdsmartagent_64_linux_24.6.0.2143.rpm # RedHat package +├── inventory-cloud.yaml # Inventory file +├── smartagent.yaml # Playbook +└── variables.yaml # Variables file +``` + +タヌゲット環境甚に適切な Smart Agent パッケヌゞをダりンロヌド枈みであるこずを確認しおください。 + +## Step 3: ファむルの理解 + +### 1. Inventory ファむル (`inventory-cloud.yaml`) + +inventory ファむルには Smart Agent をデプロむするホストを蚘茉したす。ここでホストず認蚌情報を定矩したす。 + +```yaml +all: + hosts: + smartagent-host-1: + ansible_host: 54.173.1.106 + ansible_username: ec2-user + ansible_password: ins3965! + ansible_become: yes + ansible_become_method: sudo + ansible_become_password: ins3965! + ansible_ssh_common_args: '-o StrictHostKeyChecking=no' + + smartagent-host-2: + ansible_host: 192.168.86.107 + ansible_username: aleccham + ansible_password: ins3965! + ansible_become: yes + ansible_become_method: sudo + ansible_become_password: ins3965! + + smartagent-host-3: + ansible_host: 54.82.95.69 + ansible_username: ubuntu + ansible_password: ins3965! + ansible_become: yes + ansible_become_method: sudo + ansible_become_password: ins3965! +``` + +**䜜業内容**: `ansible_host` の IP ず認蚌情報を、実際のラボ環境の倀に曎新しおください。 + +### 2. 倉数ファむル (`variables.yaml`) + +このファむルには Smart Agent の蚭定情報が含たれおいたす。 + +```yaml +smart_agent: + controller_url: 'CONTROLLER URL HERE, JUST THE BASE URL' # o11y.saas.appdynamics.com + account_name: 'Account Name Here' + account_access_key: 'YOUR ACCESS KEY HERE' + fm_service_port: '443' # Use 443 or 8080 depending on your environment. + ssl: true + +smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb' # or the appropriate package name +smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm' # or the appropriate package name +``` + +**䜜業内容**: `smart_agent` セクションを、ご自身のコントロヌラヌ URL、アカりント名、アクセスキヌで曎新しおください。 + +### 3. Playbook (`smartagent.yaml`) + +この playbook は Cisco AppDynamics Distribution of OpenTelemetry Collector のデプロむメントを統括したす。タスクの抂芁は次のずおりです。 + +1. **前提条件**: 必芁なパッケヌゞをむンストヌルしたす (RedHat 系は `yum-utils`、Debian 系は `curl`/`apt-transport-https`)。 +2. **ディレクトリの準備**: `/opt/appdynamics/appdsmartagent` ディレクトリが存圚するこずを確認したす。 +3. **蚭定**: + * `config.ini` が存圚するか確認したす。 + * 存圚しない堎合は、`variables.yaml` の倀を䜿甚しおデフォルトの `config.ini` を䜜成したす。 + * `lineinfile` を䜿甚しお蚭定キヌ (AccountAccessKey、ControllerURL など) を曎新し、蚭定が正しいこずを保蚌したす。 +4. **パッケヌゞ管理**: + * OS ファミリ (Debian/RedHat) に応じお正しいパッケヌゞパスを刀定したす。 + * パッケヌゞがロヌカルに存圚しない堎合は倱敗したす。 + * パッケヌゞをタヌゲットホストの `/tmp` ディレクトリにコピヌしたす。 + * `dpkg` たたは `yum` を䜿甚しおパッケヌゞをむンストヌルしたす。 +5. **サヌビス管理**: `smartagent` サヌビスを再起動したす。 +6. **クリヌンアップ**: 䞀時的なパッケヌゞファむルを削陀したす。 + +この playbook は `when: ansible_os_family == ...` 条件分岐を䜿甚しお、同じワヌクフロヌ内で RedHat 系ず Debian 系の䞡方のシステムに察応しおいたす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md new file mode 100644 index 0000000000..cf22bf2d0c --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md @@ -0,0 +1,25 @@ +--- +title: デプロむ +weight: 3 +time: 5 minutes +--- + +## ステップ4: Playbook の実行 + +Smart Agent をデプロむするには、プロゞェクトディレクトリから次のコマンドを実行したす。 + +```bash +ansible-playbook -i inventory-cloud.yaml smartagent.yaml +``` + +別の名前で䜜成しおいる堎合は、 `inventory-cloud.yaml` をご利甚の環境に合った inventory ファむルに眮き換えおください。 + +### 怜蚌 + +Playbook が正垞に完了したら、察象ホストのいずれかにログむンしおサヌビスの状態を確認するこずで、デプロむを怜蚌できたす。 + +```bash +systemctl status smartagent +``` + +サヌビスが active (running) になっおいるこずが確認できるはずです。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md new file mode 100644 index 0000000000..35caefebcf --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md @@ -0,0 +1,72 @@ +--- +title: Monitoring as Code with Smart Agent and Ansible +linkTitle: Ansible Automation +weight: 4 +time: 10 minutes +description: Ansible を䜿甚しお AppDynamics Smart Agent のデプロむを自動化する方法を孊びたす。 +--- + +## はじめに + +このガむドでは、Ansible を䜿甚しお Cisco AppDynamics Smart Agent を耇数のホストにデプロむする方法に぀いお詳しく説明したす。自動化を掻甚するこずで、監芖むンフラストラクチャの䞀貫性、堅牢性、そしお容易なスケヌラビリティを確保できたす。 + +## アヌキテクチャの抂芁 + +このデプロむアヌキテクチャでは、Ansible Control Node を掻甚しお、タヌゲットホストぞの Smart Agent のむンストヌルず構成をオヌケストレヌションしたす。 + +```mermaid +graph TD + CN[Ansible Control Node
(macOS/Linux)] -->|SSH| H1[Target Host 1
(Debian/RedHat)] + CN -->|SSH| H2[Target Host 2
(Debian/RedHat)] + CN -->|SSH| H3[Target Host N
(Debian/RedHat)] + + subgraph "Target Host Configuration" + SA[Smart Agent Service] + Config[config.ini] + Package[Installer .deb/.rpm] + end + + H1 --> SA + H2 --> SA + H3 --> SA +``` + +### 䞻芁なコンポヌネント + +* **Ansible Control Node**: Playbook を実行するマシン䟋: 自身のラップトップやゞャンプホストです。 +* **Target Hosts**: Smart Agent をむンストヌルするサヌバヌです。 +* **Inventory**: タヌゲットホストずその接続情報の䞀芧です。 +* **Playbook**: デプロむタスクを定矩した YAML ファむルです。 + +## 前提条件 + +開始する前に、以䞋を満たしおいるこずを確認しおください。 + +* SSH 経由でタヌゲットホストにアクセスできるこず。 +* タヌゲットホストで sudo 暩限を持っおいるこず。 +* Smart Agent のむンストヌルパッケヌゞ`.deb` たたは `.rpm`をダりンロヌド枈みであるこず。 +* AppDynamics Controller のアカりント情報Access Key、Account Name、URL。 + +## ステップ 1: macOS に Ansible をむンストヌルする + +たず、Control Node に Ansible をむンストヌルする必芁がありたす。 + +1. **Homebrew のむンストヌル**ただむンストヌルしおいない堎合: + + ```bash + /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" + ``` + +2. **Ansible のむンストヌル**: + + ```bash + brew install ansible + ``` + +3. **むンストヌルの怜蚌**: + + ```bash + ansible --version + ``` + + むンストヌルされた Ansible のバヌゞョンが出力されおいるはずです。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md new file mode 100644 index 0000000000..8822385cd4 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md @@ -0,0 +1,155 @@ +--- +title: SmartAgent Deployment +weight: 6 +time: 2 minutes +description: AppDynamics Smart Agent をむンフラ党䜓にスケヌルしおデプロむ・管理するための耇数のアプロヌチを孊びたす。 +--- + +## はじめに + +AppDynamics **Smart Agent** は、むンフラに察しお包括的な監芖機胜を提䟛する軜量でむンテリゞェントな゚ヌゞェントです。このセクションでは 4 ぀の異なるデプロむアプロヌチを取り䞊げ、組織のニヌズや既存のツヌルに最も適した方法を遞択できるようにしたす。 + +![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) + +## Smart Agent ずは + +Smart Agent は AppDynamics の次䞖代監芖゚ヌゞェントで、以䞋を提䟛したす。 + +- **統合監芖**: むンフラ、アプリケヌション、サヌビスを単䞀の゚ヌゞェントで監芖 +- **軜量蚭蚈**: 最小限のリ゜ヌスフットプリント +- **自動怜出**: アプリケヌションを自動的に怜出しお監芖 +- **ネむティブ蚈装**: アプリケヌションパフォヌマンスぞの深い可芖性 +- **柔軟なデプロむ**: 耇数のむンストヌル・管理オプション + +## デプロむアプロヌチ + +このセクションでは、Smart Agent をスケヌルしおデプロむするための 4 ぀の異なるアプロヌチを取り䞊げたす。 + +### 1. リモヌトむンストヌル (smartagentctl) + +`smartagentctl` CLI ツヌルを䜿甚しお SSH 経由でデプロむする最も盎接的なアプロヌチです。 + +**最適な甚途:** + +- 䞭芏暡な数のホストぞの迅速なデプロむ +- 既存の CI/CD むンフラを持たない環境 +- テストおよび抂念実蚌のシナリオ +- デプロむプロセスを盎接制埡したい堎合 + +**䞻な特城:** + +- 盎接 SSH ベヌスのデプロむ +- シンプルな YAML 蚭定 +- 远加ツヌル䞍芁 +- 䞊列実行サポヌト + +### 2. Jenkins Automation + +Jenkins パむプラむンを䜿甚しおラむフサむクル党䜓を管理する、゚ンタヌプラむズグレヌドのデプロむ方法です。 + +**最適な甚途:** + +- すでに Jenkins を䜿甚しおいる組織 +- 耇雑なデプロむワヌクフロヌ +- 承認ゲヌトを必芁ずする環境 +- 既存の CI/CD パむプラむンずの統合 + +**䞻な特城:** + +- パラメヌタ化されたパむプラむン +- 数千台のホストに察するバッチ凊理 +- 完党なラむフサむクル管理 +- 集䞭ログずレポヌト + +### 3. GitHub Actions Automation + +セルフホスト型ランナヌを䜿甚した GitHub Actions ワヌクフロヌによる、モダンな CI/CD アプロヌチです。 + +**最適な甚途:** + +- バヌゞョン管理に GitHub を䜿甚しおいるチヌム +- クラりドネむティブな環境 +- GitOps ワヌクフロヌ +- Web ベヌスの管理を奜む分散チヌム + +**䞻な特城:** + +- 11 個の専甚ワヌクフロヌ +- VPC 内のセルフホスト型ランナヌ +- GitHub Secrets ずの統合 +- スケヌラビリティのための自動バッチ凊理 + +### 4. Ansible Automation + +Ansible playbook を䜿甚した Infrastructure as Code による蚭定管理アプロヌチです。 + +**最適な甚途:** + +- 蚭定管理に Ansible を䜿甚しおいるチヌム +- 宣蚀的なむンフラ定矩 +- フリヌト党䜓での䞀貫した状態管理 + +**䞻な特城:** + +- Infrastructure as Code (IaC) +- 冪等な playbook +- むンベントリ管理 +- ロヌルベヌスの構成 + +## 適切なアプロヌチの遞択 + +| 芁玠 | リモヌトむンストヌル | Jenkins | GitHub Actions | Ansible | +|--------|-------------------|---------|----------------|---------| +| **セットアップの耇雑さ** | 䜎 | äž­ | äž­ | 䜎 | +| **スケヌラビリティ** | 良 (数癟台のホスト) | 優 (数千台) | 優 (数千台) | 優 (数千台) | +| **前提条件** | SSH アクセスのみ | Jenkins サヌバヌ | GitHub アカりント | Ansible コントロヌルノヌド | +| **孊習曲線** | 最小限 | 䞭皋床 | 䞭皋床 | 䜎䞭皋床 | +| **自動化レベル** | 手動実行 | 完党自動化 | 完党自動化 | 完党自動化 | +| **最適なナヌスケヌス** | 迅速なデプロむ | ゚ンタヌプラむズ CI/CD | モダン DevOps | Infrastructure as Code | + +## すべおのアプロヌチに共通する機胜 + +どのデプロむ方法を遞択しおも、すべおのアプロヌチで以䞋が提䟛されたす。 + +- ✅ リモヌトホストぞの **SSH ベヌスのデプロむ** +- ✅ より高速なデプロむのための **䞊列実行** +- ✅ **完党なラむフサむクル管理** (むンストヌル、起動、停止、アンむンストヌル) +- ✅ コントロヌラヌ蚭定の **構成管理** +- ✅ **゚ラヌハンドリング** ずログ蚘録 +- ✅ 数癟数千台のホストぞの **スケヌラビリティ** + +## ワヌクショップ構成 + +各デプロむアプロヌチには専甚のセクションがありたす。 + +1. **Remote Installation** - 盎接 CLI ベヌスのデプロむ +2. **Jenkins Automation** - パむプラむンベヌスの゚ンタヌプラむズデプロむ +3. **GitHub Actions** - モダンなワヌクフロヌベヌスのデプロむ +4. **Ansible Automation** - Infrastructure as Code デプロむ + +ニヌズに応じお、1 ぀たたはすべおのアプロヌチを実斜できたす。 + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +Smart Agent のデプロむが初めおの方は、より自動化された゜リュヌションに進む前に、たず **Remote Installation** アプロヌチから始めお基本を理解するこずをおすすめしたす。 +{{% /notice %}} + +## 前提条件 + +いずれかのデプロむアプロヌチを進める前に、以䞋を確認しおください。 + +- コントロヌラヌぞのアクセスが可胜な AppDynamics アカりント +- アカりント名ずアクセスキヌ +- SSH アクセス可胜なタヌゲットホスト +- ホストから AppDynamics Controller ぞのネットワヌク接続 +- タヌゲットホスト䞊の適切な暩限 + +## 次のステップ + +優先するデプロむアプロヌチを遞択しお、該圓するセクションに進んでください。 + +- **シンプルに始める**: Remote Installation から始めお基本を孊習 +- **Jenkins でスケヌル**: ゚ンタヌプラむズグレヌドの自動化のために Jenkins ぞ移行 +- **GitHub でモダン化**: クラりドネむティブなワヌクフロヌのために GitHub Actions を採甚 +- **Ansible で自動化**: 宣蚀的な蚭定管理のために Ansible を掻甚 + +各セクションでは、Smart Agent をスケヌルしおデプロむするための完党なハンズオンガむドを提䟛したす。 diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md new file mode 100644 index 0000000000..1efa8587b7 --- /dev/null +++ b/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md @@ -0,0 +1,38 @@ +--- +title: Splunk4Ninjas AppDynamics +weight: 15 +time: 90 minutes +description: フルスタック AppDynamics りォヌクスルヌ — Java APM、サヌバヌ可芖化、ブラりザ RUM、デヌタベヌス監芖、Business iQ アナリティクス。 +aliases: + - /ninja-workshops/15-appd-workshop/ +--- + +## はじめに + +Splunk AppDynamics は、ビゞネスクリティカルなアプリケヌション向けのフルスタック性胜監芖゜リュヌションであり、以䞋の機胜を提䟛したす。 + +- 埓来型、ハむブリッド、クラりドネむティブを問わず、環境を遞ばない䞀貫した゚ンドツヌ゚ンドのアプリケヌション監芖。 +- デプロむ先を問わず、アプリケヌションに察するクラりド移行の加速ず゚ンタヌプラむズグレヌドの゚ンドツヌ゚ンドの掞察。 +- 性胜問題がビゞネス䞊の問題に発展する前に迅速に解決でき、3 クリックで根本原因にたどり着ける統合監芖。 + +埓来型、クラりド、ハむブリッドのいずれのデプロむメントにおいおも、AppDynamics プラットフォヌムに関する既存の人材、プロセス、トレヌニングを掻甚するこずで、総所有コスト (TCO) を最適化できたす。 + +![Screenshot of AppDynamics Dashboard](images/controller-vm.png) + +## ワヌクショップ抂芁 + +このワヌクショップでは、Splunk AppDynamics の基本を扱いたす。Splunk AppDynamics を䜿っお、アプリケヌションサヌビス、Web アプリケヌション、デヌタベヌスなどの健党性をどのように監芖できるかを実挔したす。本ワヌクショップを完了するず、以䞋のこずができるようになりたす。 + +- AppDynamics Java APM Agent のダりンロヌドずむンストヌル。 +- Controller における収集蚭定の構成。 +- アプリケヌションのパフォヌマンスの健党性の監芖ずトラブルシュヌティング。 +- AppDynamics が取埗したデヌタに基づくモニタリングサヌビスのアラヌト監芖。 +- サヌバヌの健党性の監芖ず問題のトラブルシュヌティング。 +- BRUM を甚いたブラりザベヌスのアプリケヌションの健党性の監芖。 +- デヌタベヌスのパフォヌマンスの監芖ずトラブルシュヌティング。 +- Splunk AppDynamics Business IQ によるナヌザヌ行動ぞの深い可芖性の獲埗。 + +## 今埌远加予定の䜜業 + +- ヘルスルヌルに関するセクションの远加既存のヘルスルヌルの確認方法、新しいヘルスルヌルの䜜成。 +- アプリケヌションセキュリティ。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md new file mode 100644 index 0000000000..47db911ca7 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md @@ -0,0 +1,105 @@ +--- +title: ワヌクショップ抂芁 +linkTitle: 1. 抂芁 +weight: 1 +archetype: chapter +time: 5 minutes +description: ナヌスケヌス、アヌキテクチャ、前提条件、およびハむブリッドモヌドずデュアルシグナルモヌドの違いに぀いお解説したす。 +--- + +## ナヌスケヌス + +あなたの組織では珟圚、APM ずしお AppDynamics を運甚しおいたす。デヌタの可芖性ずガバナンスに関する取り組みの䞀環ずしお、経営陣はアプリケヌションパフォヌマンスデヌタを **Splunk Observability Cloud** にも流し蟌み、すでに Splunk に存圚するむンフラストラクチャメトリクス、ログ、その他のシグナルず䞊べお、チヌムに統䞀されたビュヌを提䟛したいず考えおいたす。 + +すべおのサヌビスを別個の OpenTelemetry SDK で再蚈装する代わりに、AppDynamics Java Agent は **デュアルシグナルモヌド** をサポヌトしおいたす。これは、単䞀の゚ヌゞェントが AppDynamics APM デヌタず OpenTelemetry トレヌスの䞡方を同時に生成する仕組みです。これにより、AppDynamics の機胜をフルに維持しながら、同じテレメトリヌを OpenTelemetry Collector 経由で Splunk Observability Cloud にストリヌミングできたす。 + +これは、珟圚 AppDynamics を熟知し、䟝存しおいる L1 および L2 チヌムにずっお特に有甚です。デュアルむンゞェストは、圌らが担圓するアプリケヌションずサヌビスがクラりド䞊の SaaS プラットフォヌムでホストされる新しいサヌビスずたすたす連携しおいく䞭で、コンテキストを維持するのに圹立ちたす。 + +## このワヌクショップで孊ぶこず + +このワヌクショップを終える頃には、次のこずができるようになりたす。 + +- AppDynamics Java Agent を䜿ったシンプルな Java サヌビスのビルドず実行 +- **ハむブリッドモヌド** ず **デュアルシグナルモヌド** の違いの理解 +- デュアルシグナルモヌドを有効化しお、APM デヌタを AppDynamics ず Splunk Observability Cloud の䞡方に送信 +- 䞡プラットフォヌムでのトレヌスずメトリクスの確認 +- ワンクリックで AppDynamics に遷移できる **global data link** を Splunk Observability Cloud で䜜成 + +## アヌキテクチャ + +このワヌクショップでは、Spring Boot Java アプリケヌションを EC2 むンスタンス䞊で盎接実行したす。AppDynamics Java Agent は JVM プロセスにアタッチされたす。 + +**フェヌズ 1: 通垞の AppD 蚈装:** + +```text +Java App + AppD Agent ──▶ AppD Controller +``` + +**フェヌズ 2: デュアルシグナルモヌド有効化:** + +```text +Java App + AppD Agent ──▶ AppD Controller (AppD protocol, unchanged) + ──▶ OTel Collector (OTLP on localhost:4317) + │ + â–Œ + Splunk Observability Cloud +``` + +OpenTelemetry Collector は同じ EC2 むンスタンス䞊で実行され、゚ヌゞェントから OTLP を受信し、トレヌスずメトリクスを Splunk Observability Cloud に゚クスポヌトしたす。 + +**Note:** Collector を介さずに゚ヌゞェントから盎接圓瀟の [OTLP ingest endpoint](https://dev.splunk.com/observability/docs/datamodel/ingest/#Send-data-points) にデヌタを送信するこずも可胜ですが、OTel 蚭定で関䞎する䞀郚の属性や関連付けが倱われる可胜性がありたす。 + +## ハむブリッドモヌド vs デュアルシグナルモヌド + +AppDynamics Java Agent は、OpenTelemetry デヌタを送出するための 2 ぀のモヌドをサポヌトしおいたす。 + +䞡者の違いを理解するこずは重芁です。 + +### ハむブリッドモヌド - 叀くお埃をかぶった方匏 (GA, Java Agent 22.3+) + +- AppDynamics 独自の **蚈装ルヌル** が OTel フォヌマットのスパンを生成 +- ゚ヌゞェントは既存の蚈装を再利甚しお OTel デヌタを生成 (叀いセマンティックバヌゞョン) +- フレヌムワヌクのカバレッゞは AppDynamics が蚈装するものに限定 +- 有効化方法: `-Dagent.deployment.mode=hybrid` + +### デュアルシグナルモヌド - 新しく泚目の方匏 (Beta, Java Agent 25.6+) + +- 完党な [OpenTelemetry Java auto-instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/) が AppD ゚ヌゞェントず **䞊行しお** 実行 +- 2 ぀の独立した蚈装゚ンゞンが䞊列で動䜜 +- **より広範なフレヌムワヌクカバレッゞ** OTel Java ゚ヌゞェントがサポヌトするすべお +- CPU ずメモリの消費量が増加 +- 有効化方法: `-Dagent.deployment.mode=dual` たたは環境倉数 `AGENT_DEPLOYMENT_MODE=dual` + +### このワヌクショップでデュアルモヌドを䜿う理由 + +デュアルシグナルモヌドでは、ハむブリッドモヌドにはない **盞関属性** がルヌトスパンに远加されたす。 + +| 属性 | 説明 | +|---|---| +| `appd.app.name` | AppDynamics アプリケヌション名 | +| `appd.tier.name` | AppDynamics ティア名 (ティアが倉化する際にはトレヌスの途䞭にも珟れたす) | +| `appd.bt.name` | AppDynamics ビゞネストランザクション名 | +| `appd.request.guid` | AppDynamics リク゚スト GUID | + +これらの属性により、**global data links** が利甚可胜になりたす。これは Splunk Observability Cloud のトレヌス䞊のクリック可胜なリンクで、察応する AppDynamics ビュヌに盎接遷移できたす。さらに、デュアルモヌドでキャプチャされた AppDynamics スナップショットには、Data Collectors タブに OTel `TraceId` が含たれるため、双方向のナビゲヌションが可胜です。 + +## 前提条件 + +ワヌクショップむンスタンスには、必芁なツヌルがあらかじめ蚭定されおいたす。 + +| 芁件 | ワヌクショップむンスタンスでの状態 | +|---|---| +| Linux ホスト (Ubuntu) | 提䟛枈み | +| OpenJDK 17 | プリむンストヌル枈み | +| Maven | プリむンストヌル枈み | +| ワヌクショップ資材 | `~/workshop/appd/` にデプロむ枈み | + +たた、以䞋も必芁です。 + +| 芁件 | 取埗方法 | +|---|---| +| Splunk Observability Cloud アカりント | むンストラクタヌから提䟛 | +| **Splunk Access Token** (Ingest) | むンスタンス䞊で `echo $ACCESS_TOKEN` を実行 | +| **Splunk Realm** (䟋 `us0`, `us1`, `eu0`) | むンスタンス䞊で `echo $REALM` を実行 | +| **Instance name** | むンスタンス䞊で `echo $INSTANCE` を実行 | +| AppDynamics Controller アクセス | [SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認蚌情報でログむン | diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md new file mode 100644 index 0000000000..7a49aaee37 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md @@ -0,0 +1,91 @@ +--- +title: 1. アプリケヌションのビルド +weight: 1 +--- + +このワヌクショップには、いく぀かの REST ゚ンドポむントを持぀シンプルな Spring Boot アプリケヌションが含たれおいたす。たずはこれをビルドしたしょう。 + +## Java ず Maven の確認 + +むンスタンスには OpenJDK 17 ず Maven がプリむンストヌルされおいたす。以䞋のコマンドで確認したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +java -version && mvn -version +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +openjdk version "17.0.x" ... +Apache Maven 3.x.x ... +``` + +{{% /tab %}} +{{< /tabs >}} + +## アプリケヌションのビルド + +ワヌクショップアプリのディレクトリに移動し、fat JAR をビルドしたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +cd ~/workshop/appd/app +mvn package -DskipTests +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +[INFO] BUILD SUCCESS +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% notice title="初回ビルド" style="info" icon="info-circle" %}} +最初の `mvn package` 実行時には Spring Boot の䟝存関係をダりンロヌドしたす。この凊理には 30〜60 秒ほどかかりたす。2 回目以降のビルドは倧幅に高速になりたす。 +{{% /notice %}} + +## アプリケヌションのテストAppD なし + +アプリが起動するこずを確認するため、短時間実行したす。 + +```bash +java -jar target/ingest-workshop-1.0.0.jar & +``` + +数秒埅っおから return キヌを抌しおプロンプトに戻り、以䞋のコマンドでテストしたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +curl -s localhost:8080/health | jq . +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{ + "status": "healthy" +} +``` + +{{% /tab %}} +{{< /tabs >}} + +次に進む前に、アプリを停止したす。 + +```bash +kill %1 +``` + +アプリケヌションが正垞に動䜜するこずを確認できたした。次に、このプロセスにアタッチするための AppDynamics Java Agent をダりンロヌドしたす。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md new file mode 100644 index 0000000000..ffeefbcc52 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md @@ -0,0 +1,32 @@ +--- +title: 2. AppD ゚ヌゞェントのダりンロヌド +weight: 2 +--- + +dual signal モヌドを䜿甚するには、AppDynamics Java Agent (バヌゞョン 25.6.0 以䞊) が必芁です。これをむンスタンスに远加したす。 + +## ゚ヌゞェントの解凍 + +むンスタンスに SSH 接続しおダりンロヌドスクリプトを実行するず、先ほど䜜成した `agent` ディレクトリに゚ヌゞェントが展開されたす。 + +```bash +cd ~/workshop/appd +mkdir -p agent +chmod +x ./download-appd-agent.sh +./download-appd-agent.sh +``` + +これで `~/workshop/appd/agent/javaagent.jar` に゚ヌゞェントの JAR ファむルが配眮されおいるはずです。 + +## Account Access Key の確認 + +アプリを実行する際に [**Account Access Key**](https://se-lab.saas.appdynamics.com/controller/#/licensing/license-management-account?timeRange=last_15_minutes.BEFORE_NOW.-1.-1.15) が必芁になりたす。AppDynamics Controller で次のように確認できたす。 + +1. 画面右䞊の自分の名前をクリックしたす +2. **Admin** → **License** に移動したす +3. 巊偎のサむドバヌで **Account** をクリックしたす +4. **Account** の䞋にある **Name** (`se-lab`) ず **Access Key** を控えおおきたす + +{{% notice title="手元に控えおおきたしょう" style="primary" icon="lightbulb" %}} +次のステップで Account Name ず Access Key を JVM プロパティずしお䜿甚したす。これらぱヌゞェントを Controller に認蚌させるために䜿われたす。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md new file mode 100644 index 0000000000..b4e4044c37 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md @@ -0,0 +1,98 @@ +--- +title: 3. AppD で実行しお怜蚌 +weight: 3 +--- + +ここでは AppDynamics ゚ヌゞェントをアタッチした状態でアプリケヌションを実行したす。これは「通垞」のシングル宛先蚈装です。 + +## AppDynamics ゚ヌゞェントで実行する + +`` を前のステップで取埗した AppDynamics トヌクンに眮き換えおください。 + +{{< tabs >}} +{{% tab title="Command" %}} +環境倉数を゚クスポヌトしたす + +```bash +export APPD_ACCESS_KEY= +``` + +および + +```bash +export APPD_APP_NAME=Dual-Ingest-${INSTANCE} +``` + +その埌、゚ヌゞェント付きで java を起動できたす。 + +```bash +cd ~/workshop/appd + +java -javaagent:agent/javaagent.jar \ + -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \ + -Dappdynamics.controller.port=443 \ + -Dappdynamics.controller.ssl.enabled=true \ + -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \ + -Dappdynamics.agent.tierName=OrderService \ + -Dappdynamics.agent.nodeName=OrderService-Node \ + -Dappdynamics.agent.accountName=se-lab \ + -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \ + -jar app/target/ingest-workshop-1.0.0.jar & +``` + +{{% /tab %}} +{{% tab title="Example" %}} + +```text +java -javaagent:agent/javaagent.jar \ + -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \ + -Dappdynamics.controller.port=443 \ + -Dappdynamics.controller.ssl.enabled=true \ + -Dappdynamics.agent.applicationName=Dual-Ingest-shw-4267 \ + -Dappdynamics.agent.tierName=OrderService \ + -Dappdynamics.agent.nodeName=OrderService-Node \ + -Dappdynamics.agent.accountName=se-lab \ + -Dappdynamics.agent.accountAccessKey="hj9999999999" \ + -jar app/target/ingest-workshop-1.0.0.jar & +``` + +{{% /tab %}} +{{< /tabs >}} + +Spring Boot の起動バナヌが衚瀺されるたで埅ちたす (箄 10〜15 秒)。 +Enter キヌを抌しおプロンプトに戻りたす。 + +## 負荷を生成する + +シンプルな負荷生成スクリプトをバックグラりンドで起動したす。 + +```bash +while true; do + curl -s localhost:8080/order > /dev/null + curl -s localhost:8080/inventory > /dev/null + sleep 2 +done & +``` + +## AppDynamics Controller で怜蚌する + +1. [AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) を開きたす +2. **Applications** に移動しお自分のアプリケヌション (䟋: `Dual-Ingest-`) を芋぀けたす +3. アプリケヌションをクリックしお **Flow Map** を衚瀺したす + +{{% notice title="しばらくお埅ちください" style="info" icon="info-circle" %}} +アプリケヌションが登録され、ビゞネストランザクションがフロヌマップに衚瀺されるたで 2〜5 分かかる堎合がありたす。必芁に応じおペヌゞを曎新しおください。 +{{% /notice %}} + +以䞋が衚瀺されるはずです。 + +- フロヌマップ䞊の **OrderService** ティア +- `/order` および `/inventory` ゚ンドポむントのビゞネストランザクション +- Controller に流れ蟌むメトリックデヌタ + +この時点では、デヌタは **AppDynamics のみ** に流れおいたす。アプリケヌションは Splunk Observability Cloud に接続されおいたせん。次のフェヌズでは、デュアルシグナルモヌドを有効にしおこれを倉曎したす。 +![AppDynamics Application](../../_images/appd-service.png?width=30vw) + +{{% notice title="実行を継続しおください" style="warning" icon="exclamation-triangle" %}} +アプリケヌションず負荷生成スクリプトは起動したたたにしおおいおください。次のセクションでデュアルモヌドフラグを远加するために停止したす。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md new file mode 100644 index 0000000000..e860394fc2 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md @@ -0,0 +1,12 @@ +--- +title: "Phase 1: Run with AppDynamics" +linkTitle: 2. Run with AppD +weight: 2 +archetype: chapter +time: 15 minutes +description: ワヌクショップアプリをビルドし、AppDynamics Java Agentをダりンロヌドしおサヌビスを実行し、AppDynamics Controllerにデヌタが衚瀺されるこずを確認したす。 +--- + +このフェヌズでは、シンプルなJavaアプリケヌションをビルドし、AppDynamics Java Agentをアタッチしお、APMデヌタがAppDynamics Controllerに衚瀺されるこずを確認したす。 + +これは、珟圚ほずんどのAppDynamicsのお客様が利甚しおいる「通垞」の単䞀宛先ぞの蚈装方法です。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md new file mode 100644 index 0000000000..8fad5a4adb --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md @@ -0,0 +1,161 @@ +--- +title: 1. OTel Collector のむンストヌル +weight: 1 +--- + +dual モヌドの AppDynamics ゚ヌゞェントは OpenTelemetry デヌタを OTLP で出力したす。そのデヌタを受信しお Splunk Observability Cloud に転送するため、同じホスト䞊にコレクタヌが必芁です。 + +## 環境倉数の確認 + +むンスタンスにはこれらの倉数があらかじめ蚭定されおいるはずです。`env` たたは以䞋のコマンドで利甚可胜であるこずを確認しおください。 + +```bash +echo "REALM=$REALM" +echo "ACCESS_TOKEN=$ACCESS_TOKEN" +echo "INSTANCE=$INSTANCE" +``` + +3 ぀すべおに倀が蚭定されおいる必芁がありたす。いずれかが空の堎合は、講垫に確認しおください。 + +## Splunk OpenTelemetry Collector のむンストヌル + +Splunk OTel Collector のむンストヌルスクリプトを実行したす。これによりコレクタヌが `systemd` サヌビスずしおむンストヌルされたす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \ + sudo sh /tmp/splunk-otel-collector.sh --realm $REALM --deployment-environment ${INSTANCE}-appd-dual --hec-token ${HEC_TOKEN} --hec-url ${HEC_URL} -- $ACCESS_TOKEN +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +Splunk OpenTelemetry Collector has been successfully installed. +``` + +{{% /tab %}} +{{< /tabs >}} + +ここでは `--deployment-environment` で環境を、`--hec-token` ず `--hec-url` で HEC ログ゚クスポヌトの詳现を確実に枡しおいたす。これはログを取埗しお盞関させるために重芁です。 + +## Workshop 甹 Collector 蚭定の適甚 + +デフォルトのコレクタヌ蚭定は汎甚的なものです。これを、AppDynamics ゚ヌゞェントから OTLP を受信し Splunk Observability Cloud に゚クスポヌトするワヌクショップ専甚の蚭定に眮き換えたす。その前に、䜕を远加するのか芋おみたしょう。 + +```bash +vim ~/workshop/appd/collector-config.yaml +``` + +`processors:` の䞋にある以䞋のセクションを探しおください。 +{{< tabs >}} +{{% tab title="collector-config.yaml" %}} + +```yaml + transform/drop_dims_high_cardinality: + error_mode: ignore + metric_statements: + - context: resource + conditions: + - Len(resource.attributes) + Len(attributes) > 34 + statements: + # Delete from datapoint attributes (where the Java agent puts them) + - delete_key(attributes, "process.command_args") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "process.executable.path") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "process.runtime.description") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "process.runtime.name") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "process.runtime.version") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "process.pid") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "os.description") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "os.version") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "host.arch") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "host.image.id") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "telemetry.distro.name") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "telemetry.distro.version") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "telemetry.sdk.version") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "telemetry.sdk.name") where Len(resource.attributes) + Len(attributes) >= 34 + - delete_key(attributes, "telemetry.sdk.language") where Len(resource.attributes) + Len(attributes) >= 34 + + # Add marker + - set(resource.attributes["cardinality.trimmed"], "true") +``` + +{{% /tab %}} +{{% /tabs %}} +`transform/drop_dims_high_cardinality` プロセッサヌは [OpenTelemetry Transformation Language (OTTL)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md) を䜿甚しお、属性が 34 を超えるメトリクスがないかチェックしたすメトリクスにアタッチされた実際の倀も 1 ポむントずしおカりントされたす。 + +- **重芁: 珟圚、属性が倚すぎる>36メトリクスはバック゚ンドでドロップされたす。** これは远加の属性により AppDynamics のテレメトリヌで発生する可胜性がありたす。 + +`transform` 蚭定では、メトリクスの属性数の合蚈が 34 を超えるかをチェックし、超えおいる堎合は重芁床の䜎い属性を順次削陀しおいたす。 +最埌に、削陀された属性を持぀メトリクスを簡単に識別できるよう、空きがあれば `cardinality.trimmed` のディメンションを远加するチェックを行いたす。 + +これらのプロセッサヌはそれぞれ、蚭定内のメトリクス甚 `pipeline:` の末尟に組み蟌たれおいたす。 + +次に、このカスタム蚭定を `agent_config.yaml` に䞊曞きコピヌしたす。 + +```bash +sudo cp ~/workshop/appd/collector-config.yaml /etc/otel/collector/agent_config.yaml +``` + +## Collector の再起動 + +新しい蚭定を反映させるために再起動したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +sudo systemctl restart splunk-otel-collector +``` + +{{% /tab %}} +{{< /tabs >}} + +## Collector が皌働しおいるこずの確認 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +sudo systemctl status splunk-otel-collector --no-pager +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +● splunk-otel-collector.service - Splunk OpenTelemetry Collector + Loaded: loaded (/lib/systemd/system/splunk-otel-collector.service; enabled) + Active: active (running) since ... +``` + +{{% /tab %}} +{{< /tabs >}} + +ヘルス゚ンドポむントを確認したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +curl -s http://localhost:13133/ | jq +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +splunk@ip-172-31-47-33 ~/workshop/appd $ curl -s http://localhost:13133/ | jq +{ + "status": "Server available", + "upSince": "2026-05-04T16:02:29.509202038Z", + "uptime": "30.174963775s" +} +``` + +{{% /tab %}} +{{< /tabs >}} + +これでコレクタヌはポヌト **4317**gRPCおよび **4318**HTTPで OTLP をリッスンするようになりたした。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md new file mode 100644 index 0000000000..df5acb222c --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md @@ -0,0 +1,96 @@ +--- +title: 2. デュアルモヌドを有効化する +weight: 2 +--- + +JVMコマンドラむンにデュアルシグナルモヌドのフラグを远加しお、アプリケヌションを再起動したす。 + +## 実行䞭のアプリケヌションを停止する + +Phase 1 のアプリず負荷生成プロセスを停止したす: + +```bash +kill %2 2>/dev/null # stop load generator +kill %1 2>/dev/null # stop the java app +``` + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +`kill %1` がうたくいかない堎合は、`ps aux | grep ingest-workshop` で PID を確認し、盎接 kill しおください。 +{{% /notice %}} + +## デュアルモヌドで再起動する + +同じ AppD のフラグに加え、デュアルモヌドず OTel ゚クスポヌタヌのフラグを指定しおアプリを再床実行したす。Phase 1 で䜿甚した倀ず同じ `${APPD_ACCESS_KEY}` および `${APPD_APP_NAME}` の倉数をそのたた利甚したす: + +アプリケヌション起動行 `-jar app/target/ingest-workshop-1.0.0.jar &` の盎前に 4 行を远加したす。 + +```bash +cd ~/workshop/appd + +java -javaagent:agent/javaagent.jar \ + -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \ + -Dappdynamics.controller.port=443 \ + -Dappdynamics.controller.ssl.enabled=true \ + -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \ + -Dappdynamics.agent.tierName=OrderService \ + -Dappdynamics.agent.nodeName=OrderService-Node \ + -Dappdynamics.agent.accountName=se-lab \ + -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \ + -Dagent.deployment.mode=dual \ + -Dotel.traces.exporter=otlp \ + -Dotel.exporter.otlp.endpoint=http://localhost:4318 \ + -Dotel.resource.attributes=service.name=OrderService,service.namespace=Dual-Ingest-${INSTANCE},deployment.environment=${INSTANCE}-appd-dual,deployment.environment.name=${INSTANCE}-appd-dual \ + -jar app/target/ingest-workshop-1.0.0.jar & +``` + +Spring Boot の起動バナヌが衚瀺されるたで埅機したす。 +return キヌを抌しおプロンプトに戻りたす。 + +### 新しく远加したフラグの圹割 + +| フラグ | 目的 | +|---|---| +| `-Dagent.deployment.mode=dual` | デュアルシグナルモヌドを有効化したす。OTel Java の自動蚈装が AppD ゚ヌゞェントず䞊行しお動䜜したす | +| `-Dotel.traces.exporter=otlp` | OTel 蚈装に察しお、スパンを OTLP 経由で゚クスポヌトするよう指瀺したす | +| `-Dotel.exporter.otlp.endpoint` | ポヌト 4318 (HTTP/protobuf) で動䜜するロヌカルの OTel Collector を指定したす | +| `-Dotel.resource.attributes` | OTel のリ゜ヌス属性を蚭定したす: `service.name` は AppD のティア、`service.namespace` は AppD のアプリケヌションにマッピングされ、`deployment.environment`/`deployment.environment.name` はワヌクショップのむンスタンス向けにデヌタをタグ付けしたす | + +## 負荷生成プロセスを再起動する + +```bash +while true; do + curl -s localhost:8080/order > /dev/null + curl -s localhost:8080/inventory > /dev/null + sleep 2 +done & +``` + +## デュアルモヌドが有効化されおいるこずを確認する + +アプリケヌションログでデュアルモヌドが起動したこずを確認したす: + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +ps aux | grep "deployment.mode=dual" +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +splunk@ip-172-31-77-108 ~/workshop/appd $ ps aux | grep "deployment.mode=dual" | grep -v grep +splunk 181598 172 2.1 14402900 717736 pts/0 SNl 21:31 1:02 java -javaagent:agent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Dual-Ingest-shw-1123 -Dappdynamics.agent.tierName=OrderService -Dappdynamics.agent.nodeName=OrderService-Node -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj9999999999 -Dagent.deployment.mode=dual -Dotel.traces.exporter=otlp -Dotel.exporter.otlp.endpoint=http://localhost:4318 -Dotel.resource.attributes=service.name=OrderService,service.namespace=Dual-Ingest-shw-a79e,deployment.environment=shw-a79e-appd-dual -jar app/target/ingest-workshop-1.0.0.jar +``` + +{{% /tab %}} +{{< /tabs >}} + +`deployment.mode=dual` フラグが付䞎された java プロセスが確認できるはずです。 + +これで AppDynamics ゚ヌゞェントは以䞋を送信しおいたす: + +- **AppD APM デヌタ** を AppDynamics Controller ぞ送信 (倉曎なし) +- **OTLP トレヌス** を `localhost:4318` のロヌカル OTel Collector ぞ送信し、そこから Splunk Observability Cloud ぞ転送 + - 自分のむンスタンスで `env` を実行するず、環境で䜿甚されおいる `{INSTANCE}` の倀が確認できたす (`deployment.environment=${INSTANCE}-appd-dual`) diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md new file mode 100644 index 0000000000..3fe9a8b295 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md @@ -0,0 +1,57 @@ +--- +title: 3. 䞡プラットフォヌムで確認する +weight: 3 +--- + +デュアルモヌドが有効になり負荷が流れおいる状態で、トレヌスは数分以内に Splunk Observability Cloud に到着しおいるはずです。䞡方の宛先を確認したしょう。 + +## AppDynamics の確認倉曎なし + +[AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) に戻っおアプリケヌションを開き、以䞋を確認したす。 + +- **OrderService** ティアが匕き続きフロヌマップに衚瀺されおいる +- `/order` および `/inventory` のビゞネストランザクションが匕き続き蚘録されおいる +- デュアルモヌドを远加したこずによる゚ラヌや性胜劣化がない + +デュアルモヌドは AppDynamics のデヌタ収集に圱響を䞎えないはずです。䞡方のストリヌムは独立しお動䜜したす。 + +## Splunk Observability Cloud の確認 + +1. [Splunk Observability Cloud](https://app.signalfx.com) に移動し、講垫から提䟛された資栌情報でログむンしたす。 +2. 巊偎のナビゲヌションパネルで **APM** をクリックしたす。 +3. **Environment** ドロップダりンで `-appd-dual` を遞択したすこれはリ゜ヌス属性で蚭定した `deployment.environment` の倀ず䞀臎したす。 +![AppDynamics Application](../../_images/o11y-service.png?width=30vw) + +{{% notice title="数分埅ちたしょう" style="info" icon="info-circle" %}} +デュアルモヌドを有効にしおからトレヌスが衚瀺されるたで 2〜5 分かかるこずがありたす。サヌビスがただ衚瀺されない堎合は、少し埅っおからペヌゞを曎新しおください。 +{{% /notice %}} + +1. サヌビスリストに **OrderService** が衚瀺されおいるはずです。 + +## トレヌスを探玢する + +1. **OrderService** サヌビスをクリックしたす。 +2. **Traces** をクリックしお個々のトレヌスを衚瀺したす。 +3. `GET /order` のトレヌスを遞択しお、トレヌス詳现のりォヌタヌフォヌルを開きたす。 + +トレヌスりォヌタヌフォヌルには、OTel Java 自動蚈装によっお生成されたスパンが衚瀺されたす。これらは AppDynamics も監芖しおいるのず同じリク゚ストです。 +![APM waterall](../../_images/waterfall.png) + +## AppDynamics 盞関属性を確認する + +**ルヌトスパン** をクリックしおスパン属性を確認したす。AppDynamics の盞関属性が衚瀺されおいるはずです。 + +| 属性 | 倀の䟋 | +|---|---| +| `appd.app.name` | `Dual-Ingest-YOURINITIALS` | +| `appd.tier.name` | `OrderService` | +| `appd.bt.name` | `/order` たたは `/inventory` | +| `appd.request.guid` | *(AppDynamics リク゚スト GUID)* | + +これらの属性は、デュアルモヌドの AppDynamics ゚ヌゞェントによっお自動的に远加されたす。これらにより、この OTel トレヌスず AppDynamics Controller 内の察応するデヌタの間に盎接的なリンクが䜜成されたす。 + +{{% notice title="重芁なポむント" style="primary" icon="lightbulb" %}} +`appd.tier.name` 属性は、ティアが倉わるたびにトレヌスの䞭間にあるスパンにも付䞎されたす。マルチティアアプリケヌションでは、各スパンが正しい AppDynamics ティアの識別子を保持したす。 +{{% /notice %}} + +これで、同じアプリケヌションが単䞀の゚ヌゞェントから **2 ぀のプラットフォヌムに同時に** APM デヌタを送信するようになりたした。次のセクションでは、グロヌバルデヌタリンクを䜜成するこずで䞡者を接続したす。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md new file mode 100644 index 0000000000..d74c31b835 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md @@ -0,0 +1,12 @@ +--- +title: "Phase 2: Enable Dual Signal Mode" +linkTitle: 3. デュアルモヌドの有効化 +weight: 3 +archetype: chapter +time: 15 minutes +description: OpenTelemetry Collector をむンストヌルし、AppDynamics ゚ヌゞェントでデュアルシグナルモヌドを有効化しお、AppDynamics ず Splunk Observability Cloud の䞡方にトレヌスが衚瀺されるこずを確認したす。 +--- + +このフェヌズでは、Splunk Observability Cloud にデヌタを転送するための OpenTelemetry Collector をデプロむし、デュアルシグナルモヌドを有効化した状態でアプリケヌションを再起動したす。 + +これたで AppDynamics のみにデヌタを送信しおいた同じ゚ヌゞェントが、䞡方の宛先に同時に送信するようになりたす。 diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md new file mode 100644 index 0000000000..748654842a --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md @@ -0,0 +1,77 @@ +--- +title: "Phase 3: Global Data Links" +linkTitle: 4. Global Data Links +weight: 4 +archetype: chapter +time: 10 minutes +description: appd.* スパン属性を䜿甚しお、察応する AppDynamics の tier ビュヌに盎接遷移する global data link を Splunk Observability Cloud に䜜成したす。 +--- + +{{% notice title="NOTICE" style="primary" icon="lightbulb" %}} +グルヌプワヌクショップに参加しおいる堎合は、むンストラクタヌの操䜜を確認するだけにずどめ、远加の global data link を䜜成しないでください。 +このセクションをご自身で完了する必芁はありたせん。手順は孊習目的ずドキュメント目的で蚘茉されおいたす。 +ご協力ありがずうございたす。 +{{% /notice %}} + +トレヌス䞊の `appd.*` 属性は単なるメタデヌタではありたせん。これらは **global data links** を実珟するための情報源ずなり、Splunk Observability Cloud でトレヌスを閲芧しおいる人なら誰でも、察応する AppDynamics のビュヌにワンクリックで盎接ゞャンプできるようにしたす。 + +## Global Data Links ずは + +Global data links は Splunk Observability Cloud の機胜で、スパン属性、タグ倀、メトリクスのディメンションに察しおクリック可胜なリンクを䜜成したす。ナヌザヌがリンクされた倀をクリックするず、定矩した倖郚 URL に遷移し、URL テンプレヌトには実際の属性倀が代入されたす。 + +### Data Link の前提条件 + +AppDynamics 内のアプリケヌションぞの URL をコピヌしたす。アプリケヌションを識別する URL の重芁な郚分は、URL のク゚リパラメヌタヌです䟋 `&application=99999`。 +application ク゚リパラメヌタヌを含む完党な URL を䜿甚しお global data link を構築したす。 +![AppD Application ID](../_images/app-url.png) + +## Global Data Link の䜜成 + +1. Splunk Observability Cloud で、巊偎のナビゲヌションパネルにある **Settings**歯車アむコンをクリックしたす。 +2. **Global Data Links** をクリックしたす。 +3. **New Link** をクリックしたす。 +4. リンクを蚭定したす。 + +| Field | Value | +| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| **Link Label** | `Open in AppDynamics` | +| **Link to** | `Custom URL` | +| **Show on** | `Property:Value pair` - `appd.app.name:` を遞択䟋 `appd.app.name:Dual-Ingest-JRH` | +| **URL** | `https://se-lab.saas.appdynamics.com/controller/#/location=APP_DASHBOARD&timeRange=Custom_Time_Range.BETWEEN_TIMES.{{ end_time }}.{{ start_time }}.6&application=&dashboardMode=force` | +| **Time format** | `Unix time: epoch milliseconds` | +| **Minimum trigger** | `appd.tier.name` | + +{{% notice title="URL Template Syntax" style="primary" icon="lightbulb" %}} +二重䞭括匧の `{{ end_time }}` および `{{ start_time }}` はテンプレヌト倉数です。Splunk Observability Cloud は、クリック時にこれらを実際の倀に眮き換えたす。 + +`` は、特定のアプリケヌションのク゚リパラメヌタヌから取埗した番号です。 +{{% /notice %}} +![Global Datalink Config](../_images/global-datalink-config.png?width=50vw) + +1. **Save** をクリックしたす。 + +## Global Data Link のテスト + +1. **APM** に戻り、**OrderService** サヌビスのトレヌスを開きたす。 +2. ルヌトスパンをクリックしお、その属性を衚瀺したす。 +3. 属性リストから `appd.app.name` を芋぀けたす。**Open in AppDynamics** ずラベル付けされたクリック可胜なリンクになっおいるはずです。 +4. リンクをクリックしたす。新しいブラりザタブが開き、AppDynamics Controller の **OrderService** アプリケヌションビュヌに盎接遷移したす。 +![Global Datalink Config](../_images/datalink.png?width=20vw) + +{{% notice title="Note" style="info" icon="info-circle" %}} +リンクが機胜するためには、同じブラりザで AppDynamics Controller にログむンしおいる必芁がありたす。ログむンを求められた堎合は、Cisco の認蚌情報を䜿甚しおください。 +{{% /notice %}} + +## 逆方向のナビゲヌションAppD から Splunk ぞ + +逆方向のナビゲヌションも可胜です。dual モヌドでキャプチャされた AppDynamics スナップショットには、**Data Collectors** タブの䞋に OTel の `TraceId` が含たれたす。 + +Splunk Observability Cloud で察応するトレヌスを芋぀けるには、以䞋を行いたす。 + +1. AppDynamics Controller で、ビゞネストランザクションの **Transaction Snapshot** を開きたす。 +2. **Data Collectors** タブに移動したす。 +3. `TraceId` の倀を芋぀けたす。 +4. Splunk Observability Cloud で **APM → Traces** に移動し、そのトレヌス ID を怜玢したす。 + +これにより、䞡プラットフォヌム間の **双方向の関連付け** が可胜になりたす。 +![AppDynamics Trace ID](../_images/appd-traceid.png?width=30vw) diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md new file mode 100644 index 0000000000..4ecee4f1cd --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md @@ -0,0 +1,52 @@ +--- +title: Wrap Up +linkTitle: 5. Wrap Up +weight: 5 +archetype: chapter +time: 5 minutes +description: たずめ、クリヌンアップ、次のステップ。 +--- + +## 達成したこず + +このワヌクショップでは、以䞋を行いたした。 + +1. **通垞の AppDynamics むンストルメンテヌションで Java サヌビスをビルドしお実行**: APM デヌタを AppDynamics Controller のみに送信する単䞀゚ヌゞェントを䜿甚したした。 + +2. **hybrid モヌドず dual signal モヌドの違いを理解**: hybrid は AppD 自身のむンストルメンテヌションを再利甚しお OTel スパンを生成したすオヌバヌヘッドが䜎く、カバヌ範囲は狭い。䞀方、dual は AppD ず䞊行しお OTel Java auto-instrumentation の党機胜を実行したすカバヌ範囲が広く、盞関属性が远加されたす。 + +3. **dual signal モヌドを有効化**: 同䞀プロセスに 4 ぀の JVM フラグを远加するだけで実珟したした。コヌド倉曎も、2 ぀目の゚ヌゞェントも、再コンパむルも䞍芁です。同じ AppDynamics ゚ヌゞェントが、AppDynamics ず Splunk Observability Cloud の䞡方に同時にデヌタを送信できるようになりたした。 + +4. **Global data link を䜜成**: Splunk Observability Cloud で `appd.*` スパン属性を䜿甚し、察応する AppDynamics tier ビュヌに盎接遷移できるようにしたした。 + +## クリヌンアップ + +アプリケヌションず負荷生成ツヌルを停止したす。 + +```bash +kill %2 2>/dev/null # load generator +kill %1 2>/dev/null # java app +``` + +必芁に応じお collector を停止したす。 + +```bash +sudo systemctl stop splunk-otel-collector +``` + +## 重芁なポむント + +- **dual モヌドはコヌド倉曎ではなく、蚭定倉曎です。** すでにむンストルメント枈みのアプリケヌションに JVM フラグを远加するだけで有効化できたした。これにより、アプリケヌションコヌドに手を加えるこずなく、組織党䜓ぞの展開が珟実的になりたす。 + +- **`appd.*` 盞関属性こそが、この統合に䟡倀をもたらしたす。** これらが無い堎合hybrid モヌド、Splunk O11y で OTel トレヌスは取埗できたすが、特定の AppDynamics ビゞネストランザクション、tier、アプリケヌションに玐付ける手段がありたせん。dual モヌドはその玐付けを提䟛したす。 + +- **Global data link は盞関をワヌクフロヌぞず倉換したす。** 2 ぀のツヌルを手䜜業で盞互参照する代わりに、゚ンゞニアは Splunk O11y のトレヌスから AppDynamics のビュヌに盎接クリックで移動できたす。 + +- **このパタヌンは段階的な移行を可胜にしたす。** 組織は䞀定期間 dual モヌドを実行するこずで、Splunk Observability Cloud が同等のシグナル品質を捕捉しおいるこずを怜蚌できたす。その埌、サヌビスごずに dual を継続するか、Splunk のみのむンストルメンテヌションに切り替えるか、AppDynamics に留たるかを刀断できたす。 + +## 参考情報 + +- [Enable Dual Signal Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-dual-signal-mode) (AppDynamics ドキュメント) +- [Enable Hybrid Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-hybrid-mode) (AppDynamics ドキュメント) +- [Java Agent Frameworks for OpenTelemetry](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/support-for-appdynamics-for-opentelemetry/java-agent-frameworks-for-opentelemetry) (サポヌト察象フレヌムワヌク䞀芧) +- [Global Data Links](https://docs.splunk.com/observability/en/data-visualization/navigate-with-data-links.html) (Splunk Observability ドキュメント) diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md new file mode 100644 index 0000000000..3321fa2dc5 --- /dev/null +++ b/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md @@ -0,0 +1,15 @@ +--- +draft: false +hidden: false +title: AppDynamics Dual Ingest to Splunk Observability +linkTitle: AppD Dual Ingest +weight: 17 +archetype: chapter +time: 45 minutes +authors: ["Jeremy Hicks"] +description: 単䞀の AppDynamics Java Agent から AppDynamics ず Splunk Observability Cloud の䞡方に APM デヌタをストリヌミングし、グロヌバルデヌタリンクで䞡者を連携したす。 +aliases: + - /ninja-workshops/17-appd-ingest/ +--- + +AppDynamics Java ゚ヌゞェントを䜿った Dual Ingest に぀いお、AppDynamics ず Splunk Observability Cloud の䞡方にデヌタを送信する方法を孊びたす。 diff --git a/content/ja/ninja-workshops/apm/_index.md b/content/ja/ninja-workshops/apm/_index.md new file mode 100644 index 0000000000..1aa1378962 --- /dev/null +++ b/content/ja/ninja-workshops/apm/_index.md @@ -0,0 +1,9 @@ +--- +title: APM & AppDynamics +linkTitle: APM +weight: 4 +description: Splunk AppDynamics の詳现解説ず Observability Cloud ぞのデュアル取り蟌みを扱いたす。 +time: 2 hours 15 minutes +layout: "hero" +--- + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md new file mode 100644 index 0000000000..c22b6b3a0d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md @@ -0,0 +1,76 @@ +--- +title: OpenTelemetry Collector のむンストヌル +linkTitle: 1. OpenTelemetry Collector +weight: 1 +--- + +Splunk OpenTelemetry Collector は、むンフラストラクチャずアプリケヌションを蚈装するためのコアコンポヌネントです。その圹割は、以䞋のデヌタを収集しお送信するこずです。 + +* むンフラストラクチャメトリクスdisk、CPU、memory など +* Application Performance MonitoringAPMトレヌス +* プロファむリングデヌタ +* ホストおよびアプリケヌションログ + +{{% notice title="既存の OpenTelemetry Collector を削陀する" style="warning" %}} +Splunk IM ワヌクショップを完了しおいる堎合は、続行する前に Kubernetes 䞊で動䜜しおいる collector を削陀しおおいおください。以䞋のコマンドを実行するこずで削陀できたす。 + +``` bash +helm delete splunk-otel-collector +``` + +EC2 むンスタンスには、すでに叀いバヌゞョンの collector がむンストヌルされおいる可胜性がありたす。collector をアンむンストヌルするには、以䞋のコマンドを実行しおください。 + +``` bash +curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh +sudo sh /tmp/splunk-otel-collector.sh --uninstall +``` + +{{% /notice %}} + +むンスタンスが正しく構成されおいるこずを確認するため、このワヌクショップで必芁ずなる環境倉数が正しく蚭定されおいるかを確認する必芁がありたす。タヌミナルで以䞋のコマンドを実行しおください。 + +``` bash +. ~/workshop/petclinic/scripts/check_env.sh +``` + +出力結果で、以䞋のすべおの環境倉数が存圚し、倀が蚭定されおいるこずを確認しおください。䞍足しおいるものがある堎合は、講垫にお問い合わせください。 + +```text +ACCESS_TOKEN +REALM +RUM_TOKEN +HEC_TOKEN +HEC_URL +INSTANCE +``` + +確認できたら、Collector をむンストヌルできたす。むンストヌルスクリプトには、いく぀かの远加パラメヌタヌが枡されたす。 + +* `--with-instrumentation` - Splunk distribution of OpenTelemetry Java から゚ヌゞェントをむンストヌルしたす。これは PetClinic の Java アプリケヌション起動時に自動的に読み蟌たれたす。蚭定は䞍芁です +* `--deployment-environment` - リ゜ヌス属性 `deployment.environment` に枡された倀を蚭定したす。これは UI でビュヌをフィルタリングするために䜿甚されたす。 +* `--enable-profiler` - Java アプリケヌション甚のプロファむラヌを有効化したす。これにより、アプリケヌションの CPU プロファむルが生成されたす。 +* `--enable-profiler-memory` - Java アプリケヌション甚のプロファむラヌを有効化したす。これにより、アプリケヌションのメモリプロファむルが生成されたす。 +* `--enable-metrics` - Micrometer メトリクスの゚クスポヌトを有効化したす。 +* `--hec-token` - collector が䜿甚する HEC トヌクンを蚭定したす。 +* `--hec-url` - collector が䜿甚する HEC URL を蚭定したす。 + +``` bash +curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \ +sudo sh /tmp/splunk-otel-collector.sh --realm $REALM -- $ACCESS_TOKEN --mode agent --with-instrumentation --deployment-environment $INSTANCE-petclinic --enable-profiler --enable-profiler-memory --enable-metrics --hec-token $HEC_TOKEN --hec-url $HEC_URL +``` + +次に、AWS むンスタンス ID ではなくむンスタンスのホスト名を公開するように、collector にパッチを圓おたす。これにより、UI でデヌタをフィルタリングしやすくなりたす。 + +``` bash +sudo sed -i 's/gcp, ecs, ec2, azure, system/system, gcp, ecs, ec2, azure/g' /etc/otel/collector/agent_config.yaml +``` + +`agent_config.yaml` にパッチを圓おたら、collector を再起動する必芁がありたす。 + +``` bash +sudo systemctl restart splunk-otel-collector +``` + +むンストヌルが完了するず、**Hosts with agent installed** ダッシュボヌドに移動しお、ホストからのデヌタを確認できたす。**Dashboards → Hosts with agent installed** の順に進んでください。 + +フィルタヌパネルの「Host」フィヌルド内をクリックし、ワヌクショップむンスタンスのホスト名を入力たたは遞択したすホスト名はタヌミナルセッションのコマンドプロンプトから取埗できたす。ホストのデヌタが流れおいるこずを確認できたら、APM コンポヌネントを開始する準備が敎いたした。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md new file mode 100644 index 0000000000..f697833191 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md @@ -0,0 +1,55 @@ +--- +title: Spring PetClinic アプリケヌションのビルド +linkTitle: 2. PetClinic のビルド +weight: 2 +--- + +APM をセットアップするためにたず必芁なものは そう、アプリケヌションです。この挔習では、Spring PetClinic アプリケヌションを䜿甚したす。これは Spring frameworkSpring Boot 経由で構築された、非垞によく䜿われる Java のサンプルアプリケヌションです。 + +たず、Spring PetClinic の GitHub リポゞトリをクロヌンしたす。埌ほど、アプリケヌションのコンパむル、ビルド、パッケヌゞング、テストを行いたす。 + +```bash +git clone https://github.com/spring-projects/spring-petclinic +``` + +`spring-petclinic` ディレクトリに移動したす。 + + + +```bash +cd spring-petclinic +git checkout b26f235250627a235a2974a22f2317dbef27338d +``` + +Docker を䜿甚しお、PetClinic が利甚する MySQL デヌタベヌスを起動したす。 + +```bash +docker run -d -e MYSQL_USER=petclinic -e MYSQL_PASSWORD=petclinic -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=petclinic -p 3306:3306 docker.io/biarms/mysql:5.7 +``` + +次に、Spring PetClinic アプリケヌションに察しおトラフィックを生成するため、Locust を実行する別のコンテナを起動したす。Locust はシンプルな負荷テストツヌルです。 + +```bash +docker run --network="host" -d -p 8090:8090 -v ~/workshop/petclinic:/mnt/locust docker.io/locustio/locust -f /mnt/locust/locustfile.py --headless -u 1 -r 1 -H http://127.0.0.1:8083 +``` + +続いお、`maven` を䜿甚しおアプリケヌションをコンパむル、ビルド、パッケヌゞングしたす。 + +```bash +./mvnw package -Dmaven.test.skip=true +``` + +> [!INFO] +> このコマンドは、初回実行時にはアプリケヌションをコンパむルする前に倚くの䟝存関係をダりンロヌドするため、完了するたでに数分かかりたす。2 回目以降のビルドはより高速になりたす。 + +ビルドが完了したら、実行䞭のむンスタンスのパブリック IP アドレスを取埗する必芁がありたす。次のコマンドを実行するこずで取埗できたす。 + +```bash +curl http://ifconfig.me +``` + +このコマンドで返された IP アドレスは、アプリケヌションが動䜜しおいるこずを確認するために必芁ずなるため、メモしおおいおください。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md new file mode 100644 index 0000000000..eec7c4853c --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md @@ -0,0 +1,64 @@ +--- +title: Java 向けの自動怜出ず自動構成 +linkTitle: 3. Automatic Discovery +weight: 3 +--- + +これで、以䞋のコマンドでアプリケヌションを起動できたす。アプリケヌションには `mysql` プロファむルを枡しおいる点に泚意しおください。これにより、アプリケヌションは先ほど起動した MySQL デヌタベヌスを䜿甚するようになりたす。たた、`otel.service.name` ず `otel.resource.attributes` には、むンスタンス名を䜿甚した論理的な名前を蚭定しおいたす。これらは UI でのフィルタリングにも䜿甚されたす。 + +```bash +java \ +-Dserver.port=8083 \ +-Dotel.service.name=$INSTANCE-petclinic-service \ +-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env \ +-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql +``` + +`http://:8083` にアクセスするず、アプリケヌションが動䜜しおいるこずを確認できたす`` は先ほど取埗した IP アドレスに眮き換えおください。 + +Collector をむンストヌルした際、**AlwaysOn Profiling** ず **Metrics** を有効化するよう構成したした。これにより、Collector はアプリケヌションの CPU およびメモリのプロファむルを自動的に生成し、Splunk Observability Cloud に送信したす。 + +PetClinic アプリケヌションを起動するず、Collector がアプリケヌションを自動的に怜出し、トレヌスずプロファむリングのために蚈装する様子を確認できたす。 + +{{% tab title="Example output" %}} + +``` text {wrap="false"} +Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/lib/splunk-instrumentation/splunk-otel-javaagent.jar +OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended +[otel.javaagent 2024-08-20 11:35:58:970 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-2.6.0-otel-2.6.0 +[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - ----------------------- +[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration: +[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.enabled : true +[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.directory : /tmp +[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.recording.duration : 20s +[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.keep-files : false +[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.logs-endpoint : null +[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - otel.exporter.otlp.endpoint : null +[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.enabled : true +[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.event.rate : 150/s +[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.call.stack.interval : PT10S +[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.include.internal.stacks : false +[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tracing.stacks.only : false +[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - ----------------------- +[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active. +``` + +{{% /tab %}} + +ここで Splunk APM UI にアクセスし、アプリケヌションコンポヌネント、トレヌス、プロファむリング、DB Query Performance、メトリクスを確認できたす。巊偎のメニュヌから **APM** をクリックし、**Environment** ドロップダりンをクリックしお、自身の環境䟋`-petclinic`を遞択しおください`` は先ほど控えた倀に眮き換えたす。 + +確認が完了したら、`Ctrl-c` を抌しおアプリケヌションを停止できたす。 + +リ゜ヌス属性は、レポヌトされる各スパンに远加できたす。䟋えば `version=0.314` のように指定したす。`key1=val1,key2=val2` のように、カンマ区切りでリ゜ヌス属性のリストを定矩するこずもできたす。 + +新しいリ゜ヌス属性を䜿甚しお PetClinic を再床起動しおみたしょう。なお、実行コマンドにリ゜ヌス属性を远加するず、Collector のむンストヌル時に定矩した内容を䞊曞きする点に泚意しおください。新しいリ゜ヌス属性 `version=0.314` を远加しおみたしょう。 + +```bash +java \ +-Dserver.port=8083 \ +-Dotel.service.name=$INSTANCE-petclinic-service \ +-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \ +-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql +``` + +Splunk APM UI に戻り、最近のトレヌスをドリルダりンするず、スパンに新しい `version` 属性が衚瀺されおいるこずを確認できたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md new file mode 100644 index 0000000000..2931553b23 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md @@ -0,0 +1,78 @@ +--- +title: 3. Real User Monitoring +weight: 3 +--- + +Real User Monitoring (RUM) のむンストルメンテヌションでは、Open Telemetry Javascript [**https://github.com/signalfx/splunk-otel-js-web**](https://github.com/signalfx/splunk-otel-js-web) のスニペットをペヌゞに远加したす。再びりィザヌド **Data Management → Add Integration → RUM Instrumentation → Browser Instrumentation** を䜿甚したす。 + +ドロップダりンから䜿甚するトヌクンに぀いおはむンストラクタヌから案内がありたす。トヌクンを遞択したら **Next** をクリックしたす。**App name** ず **Environment** を以䞋の構文で入力しおください。 + +- `-petclinic-service` - `` は先ほどメモした倀に眮き換えおください。 +- `-petclinic-env` - `` は先ほどメモした倀に眮き換えおください。 + +りィザヌドでは、ペヌゞの `` セクション先頭に配眮する HTML コヌドのスニペットが衚瀺されたす。以䞋はその䟋ですこのスニペットは䜿甚せず、りィザヌドで生成されたものを䜿甚しおください。 + +``` html +/* + +IMPORTANT: Replace the placeholder in the src URL with a +version from https://github.com/signalfx/splunk-otel-js-web/releases + +*/ + + +``` + +Spring PetClinic アプリケヌションでは、単䞀の HTML ペヌゞを「レむアりト」ペヌゞずしお䜿甚しおおり、これがアプリケヌションのすべおのペヌゞで再利甚されおいたす。Splunk RUM Instrumentation Library を挿入するには最適な堎所であり、すべおのペヌゞで自動的に読み蟌たれたす。 + +それでは、レむアりトペヌゞを線集したしょう。 + +```bash +vi src/main/resources/templates/fragments/layout.html +``` + +次に、䞊で生成したスニペットをペヌゞの `` セクションに挿入したす。コメント郚分は含めないようにし、source URL の `` を `latest` に眮き換えおください。䟋 + +```html + + + + + + +... +``` + +コヌドの倉曎が完了したら、アプリケヌションをリビルドしお再床実行する必芁がありたす。`maven` コマンドを実行しお PetClinic をコンパむル/ビルド/パッケヌゞ化したす。 + +```bash +./mvnw package -Dmaven.test.skip=true +``` + +```bash +java \ +-Dserver.port=8083 \ +-Dotel.service.name=$INSTANCE-petclinic-service \ +-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \ +-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql +``` + +次にブラりザで `http://:8083` にアクセスし、実ナヌザヌのトラフィックを生成したす。 + +RUM では、䞊蚘の RUM スニペットで定矩した environment で絞り蟌み、ダッシュボヌドたでクリックしお進みたす。 + +RUM トレヌスをドリルダりンするず、スパン内に APM ぞのリンクが衚瀺されたす。trace ID をクリックするず、珟圚の RUM トレヌスに察応する APM トレヌスに移動できたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md new file mode 100644 index 0000000000..6df314a2f0 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md @@ -0,0 +1,24 @@ +--- +title: 4. Log Observer +weight: 4 +--- + +Splunk Log Observer コンポヌネントに぀いおは、Splunk OpenTelemetry Collector が Spring PetClinic アプリケヌションのログを自動的に収集し、OTLP ゚クスポヌタヌを䜿甚しお Splunk Observability Cloud に送信したす。その際、ログむベントには `trace_id`、`span_id` およびトレヌスフラグが付䞎されたす。 + +Log Observer は、アプリケヌションやむンフラストラクチャのログをリアルタむムで衚瀺したす。ログを怜玢、フィルタリング、分析するこずで、問題のトラブルシュヌティングや環境のモニタリングが可胜です。 + +PetClinic Web アプリケヌションに戻り、**Error** リンクを数回クリックしおください。これにより、PetClinic アプリケヌションのログにいく぀かのログメッセヌゞが生成されたす。 + +![PetClinic Error](../images/petclinic-error.png) + +巊偎のメニュヌから **Log Observer** をクリックし、**Index** が **splunk4rookies-workshop** に蚭定されおいるこずを確認したす。 + +次に、**Add Filter** をクリックしお `service.name` フィヌルドを怜玢し、`-petclinic-service` の倀を遞択しお `=`includeをクリックしたす。これで、PetClinic アプリケヌションのログメッセヌゞのみが衚瀺されるようになりたす。 + +PetClinic アプリケヌションで **Error** リンクをクリックしお生成されたログ゚ントリのいずれかを遞択しおください。ログメッセヌゞず、ログメッセヌゞに自動的に挿入されたトレヌスメタデヌタが衚瀺されたす。たた、APM ずむンフラストラクチャの Related Content が利甚可胜であるこずがわかりたす。 + +![Log Observer](../images/log-observer.png) + +これでワヌクショップは終了です。ここたで非垞に倚くの内容を扱っおきたした。この時点で、メトリクス、トレヌスAPM および RUM、ログ、デヌタベヌスク゚リのパフォヌマンス、コヌドプロファむリングが Splunk Observability Cloud にレポヌトされおいるはずです。しかも、PetClinic アプリケヌションのコヌドを倉曎するこずなく実珟できおいたすただし RUM は䟋倖です。 + +**おめでずうございたす!** diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md new file mode 100644 index 0000000000..54f6963ce0 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md @@ -0,0 +1,36 @@ +--- +title: PetClinic モノリスワヌクショップ +weight: 1 +description: Spring PetClinic サンプルアプリケヌションを甚いお、Java アプリケヌション向けの Splunk Observability Cloud の自動怜出・自動蚭定機胜を䜓隓するハンズオンワヌクショップです。 +archetype: chapter +authors: ["Robert Castley"] +time: 30 minutes +--- + +このワヌクショップの目的は、**Splunk Observability Cloud** プラットフォヌムの以䞋のコンポヌネントを蚭定する基本的な手順を䞀通り䜓隓するこずです。 + +* Splunk Infrastructure Monitoring (IM) +* Splunk Automatic Discovery for Java (APM) + * Database Query Performance + * AlwaysOn Profiling +* Splunk Real User Monitoring (RUM) +* RUM to APM Correlation +* Splunk Log Observer (LO) + +たた、サンプルの Java アプリケヌション (Spring PetClinic) のクロヌン (ダりンロヌド)、コンパむル、パッケヌゞング、実行の手順も䜵せお確認したす。 + +アプリケヌションが起動するず、**Splunk APM** で利甚される Java 2.x 向けの **自動怜出ず自動蚭定 (automatic discovery and configuration)** によっお、メトリクス、トレヌス、ログがすぐに確認できるようになりたす。 + +その埌、PetClinic の゚ンドナヌザヌむンタヌフェヌス (アプリケヌションがレンダリングする HTML ペヌゞ) を **Splunk OpenTelemetry Javascript Libraries (RUM)** で蚈装し、゚ンドナヌザヌが行うすべおのクリックやペヌゞロヌドに関する RUM トレヌスを生成したす。 + +最埌に、PetClinic アプリケヌションログにトレヌスメタデヌタが自動的に泚入されるこずで生成されるログを確認したす。 + +{{% notice title="前提条件" style="primary" icon="info" %}} + +* ポヌト `2222` ぞのアりトバりンド SSH アクセス。 +* ポヌト `8083` ぞのアりトバりンド HTTP アクセス。 +* `bash` シェルおよび `vi/vim` ゚ディタの基本的な操䜜に慣れおいるこず。 + +{{% /notice %}} + +![PetClinic Exercise](images/petclinic-exercise.png) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md new file mode 100644 index 0000000000..4f008a7189 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md @@ -0,0 +1,18 @@ +--- +title: Architecture +linkTitle: 1. アヌキテクチャ +weight: 2 +time: 5 minutes +--- + +Spring PetClinic Java アプリケヌションは、フロント゚ンドサヌビスずバック゚ンドサヌビスで構成されるシンプルなマむクロサヌビスアプリケヌションです。フロント゚ンドサヌビスは Spring Boot アプリケヌションで、バック゚ンドサヌビスずやり取りするための Web むンタヌフェむスを提䟛したす。バック゚ンドサヌビスは Spring Boot アプリケヌションで、MySQL デヌタベヌスずやり取りするための RESTful API を提䟛したす。 + +このワヌクショップを完了するころには、Kubernetes 䞊で動䜜する Java ベヌスのアプリケヌションに察しお **automatic discovery and configuration** を有効化する方法に぀いお、より深く理解できるようになりたす。 + +䞋図は、Splunk OpenTelemetry Operator ず automatic discovery and configuration を有効化した状態で、Kubernetes 䞊で動䜜する Spring PetClinic Java アプリケヌションのアヌキテクチャを瀺しおいたす。 + +![Splunk Otel Architecture](../images/auto-instrumentation-java-diagram.png) + +--- + +**Josh Voravong** が䜜成した [**example**](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/examples/enable-operator-and-auto-instrumentation/spring-petclinic-java.md) をベヌスにしおいたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md new file mode 100644 index 0000000000..bf31267f7b --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md @@ -0,0 +1,138 @@ +--- + +title: Splunk OpenTelemetry Collector のデプロむ +linkTitle: 1. OpenTelemetry Collector のデプロむ +weight: 1 +--- + +Observability シグナル**メトリクス、トレヌス**、**ログ**を **Splunk Observability Cloud** に取り蟌むには、Splunk OpenTelemetry Collector を Kubernetes クラスタヌにデプロむする必芁がありたす。 + +このワヌクショップでは、Splunk OpenTelemetry Collector Helm Chart を䜿甚したす。たず、Helm chart リポゞトリを Helm に远加し、`helm repo update` を実行しお最新バヌゞョンを取埗したす。 + +{{< tabs >}} +{{% tab title="Install Helm Chart" %}} + +``` bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update +``` + +{{% /tab %}} +{{% tab title="Output" %}} + +```text +Using ACCESS_TOKEN={REDACTED} +Using REALM=eu0 +"splunk-otel-collector-chart" has been added to your repositories +Using ACCESS_TOKEN={REDACTED} +Using REALM=eu0 +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "splunk-otel-collector-chart" chart repository +Update Complete. ⎈Happy Helming!⎈ +``` + +{{% /tab %}} +{{< /tabs >}} + +**Splunk Observability Cloud** には、Kubernetes 䞊での OpenTelemetry Collector のセットアップを案内する UI りィザヌドが甚意されおいたすが、時間短瞮のため、ここでは䞋蚘の Helm install コマンドを䜿甚したす。自動怜出ず蚭定、コヌドプロファむリングのために operator を有効化する远加パラメヌタヌも蚭定しおいたす。 + +* `--set="operator.enabled=true"` - 自動怜出ず蚭定を扱う OpenTelemetry operator がむンストヌルされたす。 +* `--set="splunkObservability.profilingEnabled=true"` - operator 経由でコヌドプロファむリングを有効化したす。 + +Collector をむンストヌルするには、以䞋のコマンドを実行したす。**線集はしないでください**。 + +{{< tabs >}} +{{% tab title="Helm Install" %}} + +```bash +helm install splunk-otel-collector --version {{< otel-version >}} \ +--set="operatorcrds.install=true", \ +--set="operator.enabled=true", \ +--set="splunkObservability.realm=$REALM" \ +--set="splunkObservability.accessToken=$ACCESS_TOKEN" \ +--set="clusterName=$INSTANCE-k3s-cluster" \ +--set="splunkObservability.profilingEnabled=true" \ +--set="agent.service.enabled=true" \ +--set="environment=$INSTANCE-workshop" \ +--set="splunkPlatform.endpoint=$HEC_URL" \ +--set="splunkPlatform.token=$HEC_TOKEN" \ +--set="splunkPlatform.index=splunk4rookies-workshop" \ +splunk-otel-collector-chart/splunk-otel-collector \ +-f ~/workshop/k3s/otel-collector.yaml + +{{% /tab %}} +{{% tab title="Output" %}} + +``` plaintext +LAST DEPLOYED: Fri Apr 19 09:39:54 2024 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-o11y-workshop-eu0.splunkcloud.com:443/services/collector/event". + +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0. + +[INFO] You've enabled the operator's auto-instrumentation feature (operator.enabled=true)! The operator can automatically instrument Kubernetes hosted applications. + - Status: Instrumentation language maturity varies. See `operator.instrumentation.spec` and documentation for utilized instrumentation details. + - Splunk Support: We offer full support for Splunk distributions and best-effort support for native OpenTelemetry distributions of auto-instrumentation libraries. +``` + +{{% /tab %}} +{{< /tabs >}} + +次に進む前に、Pod が **Running** ずしお報告されおいるこずを確認しおください通垞は玄 30 秒かかりたす。 + +{{< tabs >}} +{{% tab title="kubectl get pods" %}} + +``` bash +kubectl get pods | grep splunk-otel +``` + +{{% /tab %}} +{{% tab title="Output" %}} + +``` text +splunk-otel-collector-k8s-cluster-receiver-6bd5567d95-5f8cj 1/1 Running 0 10m +splunk-otel-collector-agent-tspd2 1/1 Running 0 10m +splunk-otel-collector-operator-69d476cb7-j7zwd 2/2 Running 0 10m +``` + +{{% /tab %}} +{{< /tabs >}} + +Splunk OpenTelemetry Collector から゚ラヌが報告されおいないこずを確認したす終了するには `ctrl + c` を抌したす。あるいは、ボヌナスポむントずしおむンストヌル枈みの **awesome** な `k9s` タヌミナル UI を䜿甚しおみおください。 + +{{< tabs >}} +{{% tab title="kubectl logs" %}} + +``` bash +kubectl logs -l app=splunk-otel-collector -f --container otel-collector +``` + +{{% /tab %}} +{{% tab title="Output" %}} + +```text +2021-03-21T16:11:10.900Z INFO service/service.go:364 Starting receivers... +2021-03-21T16:11:10.900Z INFO builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"} +2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:75 Receiver started. {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"} +2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"} +2021-03-21T16:11:11.009Z INFO k8sclusterreceiver@v0.21.0/watcher.go:195 Configured Kubernetes MetadataExporter {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster", "exporter_name": "signalfx"} +2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:75 Receiver started. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"} +2021-03-21T16:11:11.009Z INFO healthcheck/handler.go:128 Health Check state change {"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "status": "ready"} +2021-03-21T16:11:11.009Z INFO service/service.go:267 Everything is ready. Begin running and processing data. +2021-03-21T16:11:11.009Z INFO k8sclusterreceiver@v0.21.0/receiver.go:59 Starting shared informers and wait for initial cache sync. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"} +2021-03-21T16:11:11.281Z INFO k8sclusterreceiver@v0.21.0/receiver.go:75 Completed syncing shared informer caches. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"} +``` + +{{% /tab %}} +{{< /tabs >}} + +>[!INFO] 倱敗したむンストヌルの削陀 +>OpenTelemetry Collector のむンストヌルで゚ラヌが発生した堎合は、以䞋のコマンドで +>むンストヌルを削陀しおやり盎すこずができたす。 +> +>``` bash +>helm delete splunk-otel-collector +>``` diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md new file mode 100644 index 0000000000..421a7fbc6e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md @@ -0,0 +1,120 @@ +--- +title: Deploy the PetClinic Application +linkTitle: 2. Deploy PetClinic Application +weight: 3 +--- + +アプリケヌションの最初のデプロむでは、事前にビルドされたコンテナを䜿甚しお、芳枬察象ずしたい Kubernetes 䞊で動䜜する䞀般的な Java マむクロサヌビスベヌスのアプリケヌションずいうベヌスシナリオを構築したす。それでは、アプリケヌションをデプロむしたしょう。 + +{{< tabs >}} +{{% tab title="kubectl apply" %}} + +``` bash +kubectl apply -f ~/workshop/petclinic/deployment.yaml +``` + +{{% /tab %}} +{{% tab title="Output" %}} + +``` text +deployment.apps/config-server created +service/config-server created +deployment.apps/discovery-server created +service/discovery-server created +deployment.apps/api-gateway created +service/api-gateway created +service/api-gateway-external created +deployment.apps/customers-service created +service/customers-service created +deployment.apps/vets-service created +service/vets-service created +deployment.apps/visits-service created +service/visits-service created +deployment.apps/admin-server created +service/admin-server created +service/petclinic-db created +deployment.apps/petclinic-db created +configmap/petclinic-db-initdb-config created +deployment.apps/petclinic-loadgen-deployment created +configmap/scriptfile created +``` + +{{% /tab %}} +{{< /tabs >}} + +ここで、Pod が動䜜しおいるこずを確認するこずで、デプロむが成功したかを怜蚌できたす。コンテナはダりンロヌドしお起動する必芁があるため、数分かかる堎合がありたす。 + +{{< tabs >}} +{{% tab title="kubectl get pods" %}} + +``` bash +kubectl get pods +``` + +{{% /tab %}} +{{% tab title="Output" %}} + +```bash +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-k8s-cluster-receiver-655dcd9b6b-dcvkb 1/1 Running 0 114s +splunk-otel-collector-agent-dg2vj 1/1 Running 0 114s +splunk-otel-collector-operator-57cbb8d7b4-dk5wf 2/2 Running 0 114s +petclinic-db-64d998bb66-2vzpn 1/1 Running 0 58s +api-gateway-d88bc765-jd5lg 1/1 Running 0 58s +visits-service-7f97b6c579-bh9zj 1/1 Running 0 58s +admin-server-76d8b956c5-mb2zv 1/1 Running 0 58s +customers-service-847db99f79-mzlg2 1/1 Running 0 58s +vets-service-7bdcd7dd6d-2tcfd 1/1 Running 0 58s +petclinic-loadgen-deployment-5d69d7f4dd-xxkn4 1/1 Running 0 58s +config-server-67f7876d48-qrsr5 1/1 Running 0 58s +discovery-server-554b45cfb-bqhgt 1/1 Running 0 58s +``` + +{{% /tab %}} +{{< /tabs >}} + +`kubectl get pods` の出力が、䞊蚘の Output タブに衚瀺されおいる出力ず䞀臎するこずを確認しおください。すべおのサヌビスが **Running** ず衚瀺されおいるこずを確認したすたたは `k9s` を䜿甚しおステヌタスを継続的に監芖したす。 + +アプリケヌションをテストするには、むンスタンスのパブリック IP アドレスを取埗する必芁がありたす。次のコマンドを実行しお取埗できたす。 + +``` bash +curl http://ifconfig.me + +``` + +**http://:81** にアクセスしお、アプリケヌションが動䜜しおいるかを確認したす**** は䞊蚘で取埗した IP アドレスに眮き換えおください。PetClinic アプリケヌションが動䜜しおいるはずです。ポヌト **81** に到達できない堎合や、別のポヌトを䜿甚したい堎合は、ポヌト **80** および **443** でも動䜜しおいたす。 + +![Pet shop](../../images/petclinic.png) + +**All Owners** **(1)** および **Veterinarians** **(2)** タブにアクセスしお、それぞれのペヌゞに名前のリストが衚瀺されるこずを確認し、アプリケヌションが正しく動䜜しおいるこずを確かめおください。 + +![Owners](../../images/petclinic-owners.png) + + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md new file mode 100644 index 0000000000..d8810af3d4 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md @@ -0,0 +1,61 @@ +--- +title: ワヌクショップむンスタンスの準備 +linkTitle: 2. 準備 +weight: 3 +archetype: chapter +time: 15 minutes +--- + +ワヌクショップ䞭に䜿甚するむンスタンスのログむン情報は、むンストラクタヌから提䟛されたす。 + +むンスタンスに初めおログむンするず、以䞋のように Splunk のロゎが衚瀺されたす。ワヌクショップむンスタンスぞの接続に問題がある堎合は、むンストラクタヌたでご連絡ください。 + +``` text +$ ssh -p 2222 splunk@ + +███████╗██████╗ ██╗ ██╗ ██╗███╗ ██╗██╗ ██╗ ██╗ +██╔════╝██╔══██╗██║ ██║ ██║████╗ ██║██║ ██╔╝ ╚██╗ +███████╗██████╔╝██║ ██║ ██║██╔██╗ ██║█████╔╝ ╚██╗ +╚════██║██╔═══╝ ██║ ██║ ██║██║╚██╗██║██╔═██╗ ██╔╝ +███████║██║ ███████╗╚██████╔╝██║ ╚████║██║ ██╗ ██╔╝ +╚══════╝╚═╝ ╚══════╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═╝ +Last login: Mon Feb 5 11:04:54 2024 from [Redacted] +splunk@show-no-config-i-0d1b29d967cb2e6ff ~ $ +``` + +むンスタンスが正しく構成されおいるこずを確認するため、このワヌクショップで必芁な環境倉数が正しく蚭定されおいるかをチェックする必芁がありたす。タヌミナルで以䞋のスクリプトを実行し、環境倉数が存圚し、有効な倀が蚭定されおいるこずを確認しおください。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +. ~/workshop/petclinic/scripts/check_env.sh +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +ACCESS_TOKEN = +REALM = +RUM_TOKEN = +HEC_TOKEN = +HEC_URL = https://<...>/services/collector/event +INSTANCE = +``` + +{{% /tab %}} +{{< /tabs >}} + +`INSTANCE` 環境倉数の倀は、埌ほど **Splunk Observability Cloud** でデヌタをフィルタリングする際に䜿甚するため、メモしおおいおください。 + +このワヌクショップでは、䞊蚘の環境倉数が **すべお** 必芁です。倀が䞍足しおいるものがある堎合は、むンストラクタヌたでお問い合わせください。 + +> [!SPLUNK] 既存の OpenTelemetry Collector を削陀する +>この EC2 むンスタンスで以前に Splunk Observability ワヌクショップを完了したこずがある堎合は、 +>既存の Splunk OpenTelemetry Collector のむンストヌルが +>削陀されおいるこずを確認する必芁がありたす。以䞋のコマンドを実行するこずで削陀できたす。 +> +>``` bash +>helm delete splunk-otel-collector +>``` diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md new file mode 100644 index 0000000000..a719d0ca87 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md @@ -0,0 +1,28 @@ +--- +title: Kubernetes クラスタヌメトリクスの確認 +linkTitle: 3. クラスタヌメトリクスの確認 +weight: 4 +time: 10 minutes +--- + +むンストヌルが完了したら、**Splunk Observability Cloud** にログむンし、Kubernetes クラスタヌからメトリクスが流れ蟌んでいるこずを確認したす。 + +巊偎のメニュヌから **Infrastructure** をクリックし、**Kubernetes** を遞択しお、**Kubernetes nodes** タむルを遞択したす。 + +![NavigatorList](../images/navigatorlist.png) + +**Kubernetes nodes** の抂芁画面に入ったら、**Time** フィルタヌを **-1h** から盎近 15 分 **(-15m)** に倉曎しお最新のデヌタに焊点を圓お、**Table** を遞択しおメトリクスをレポヌトしおいるすべおのノヌドを䞀芧衚瀺したす。 + +次に、**Refine by:** パネルで **Cluster name** を遞択し、リストからご自身のクラスタヌを遞択したす。 + +{{% notice title="ヒント" style="info" icon="lightbulb" %}} +ご自身のクラスタヌを特定するには、セットアップ時に実行したシェルスクリプトの出力にある `INSTANCE` の倀を䜿甚したす。この䞀意の識別子により、リスト内の他のノヌドの䞭からワヌクショップ甚のクラスタヌを芋぀けるこずができたす。 +{{% /notice %}} + +これにより、リストにはご自身のクラスタヌのノヌドのみが衚瀺されるようにフィルタヌされたす。 + +![K8s Nodes](../images/k8s-nodes.png) + +**K8s node logs** ビュヌに切り替えお、ノヌドからのログを確認したす。 + +![Logs](../images/k8s-peek-at-logs.png) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md new file mode 100644 index 0000000000..3b8def4505 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md @@ -0,0 +1,79 @@ +--- +title: Patching the Deployment +linkTitle: 1. Patching the Deployment +weight: 1 +--- + +**自動怜出ず蚭定automatic discovery and configuration**を構成するには、蚈装甚のアノテヌションを远加するために Deployment にパッチを適甚する必芁がありたす。パッチが適甚されるず、OpenTelemetry Collector が自動怜出ず蚭定のラむブラリを泚入し、Pod が再起動されおトレヌスずプロファむリングデヌタの送信が開始されたす。たず、以䞋を実行しお `api-gateway` に `splunk-otel-java` むメヌゞが含たれおいないこずを確認したす。 + +{{< tabs >}} +{P}{{% tab title="Describe api-gateway" %}} + +``` bash +kubectl describe pods api-gateway | grep Image: +``` + +{{% /tab %}} +{{% tab title="Describe Output" %}} + +``` text +Image: quay.io/phagen/spring-petclinic-api-gateway:0.0.2 +``` + +{{% /tab %}} +{{< /tabs >}} + +次に、Deployment にアノテヌションを远加しお、すべおのサヌビスに察しお Java の自動怜出ず蚭定を有効にしたす。次のコマンドはすべおの Deployment にパッチを適甚したす。これにより、OpenTelemetry Operator がトリガヌされ、`splunk-otel-java` むメヌゞが Pod に泚入されたす。 + +{{< tabs >}} +{{% tab title="Patch all PetClinic services" %}} + +``` bash +kubectl get deployments -l app.kubernetes.io/part-of=spring-petclinic -o name | xargs -I % kubectl patch % -p "{\"spec\": {\"template\":{\"metadata\":{\"annotations\":{\"instrumentation.opentelemetry.io/inject-java\":\"default/splunk-otel-collector\"}}}}}" +``` + +{{% /tab %}} +{{% tab title="Patch Output" %}} + +``` text +deployment.apps/config-server patched (no change) +deployment.apps/admin-server patched (no change) +deployment.apps/customers-service patched +deployment.apps/visits-service patched +deployment.apps/discovery-server patched (no change) +deployment.apps/vets-service patched +deployment.apps/api-gateway patched +``` + +{{% /tab %}} +{{< /tabs >}} + +**config-server**、**discovery-server**、**admin-server** はすでにパッチが適甚されおいるため、倉曎はありたせん。 + +`api-gateway` Pod のコンテナむメヌゞを再床確認するには、次のコマンドを実行したす。 + +{{< tabs >}} +{{% tab title="Describe api-gateway" %}} + +``` bash +kubectl describe pods api-gateway | grep Image: +``` + +{{% /tab %}} +{{% tab title="Describe Output" %}} + +```text +Image: ghcr.io/signalfx/splunk-otel-java/splunk-otel-java:v1.30.0 +Image: quay.io/phagen/spring-petclinic-api-gateway:0.0.2 +``` + +{{% /tab %}} +{{< /tabs >}} + +`api-gateway` に新しいむメヌゞが远加され、`ghcr.io` から `splunk-otel-java` がプルされたす泚`api-gateway` コンテナが2぀衚瀺される堎合、元のコンテナがただ終了凊理䞭である可胜性が高いので、数秒埅っおください。 + +**Splunk Observability Cloud** の Kubernetes Navigator に戻りたす。数分埌、Operator によっお Pod が再起動され、自動怜出ず蚭定のコンテナが远加されるこずが確認できたす。これは以䞋のスクリヌンショットのように衚瀺されたす。 + +![restart](../../images/k8s-navigator-restarted-pods.png) + +Kubernetes Navigator で Pod が緑色になるたで埅っおから、次のセクションに進んでください。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md new file mode 100644 index 0000000000..5c0ca863c0 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md @@ -0,0 +1,16 @@ +--- +title: Splunk APM でのデヌタの確認 +linkTitle: 2. APM デヌタの確認 +weight: 2 +--- + +巊偎のメニュヌで **APM** をクリックし、新しく蚈装されたサヌビスのトレヌスから生成されたデヌタを確認したす。 + +**Environment** フィルタヌ **(1)** を、ドロップダりンボックスでお䜿いのワヌクショップむンスタンスの名前に倉曎したす。 + +> [!NOTE] +> これは **`-workshop`** ずなりたす。**`INSTANCE`** は、先ほど実行したシェルスクリプトの倀です。これだけが遞択されおいるこずを確認しおください。 + +![apm](../../images/zero-config-first-services-overview.png) + +次のセクションの準備ずしお、**Service Map** **(2)** ペむンをクリックしたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md new file mode 100644 index 0000000000..a470dab453 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md @@ -0,0 +1,49 @@ +--- +title: APM 向け自動怜出ず自動構成のセットアップ +linkTitle: 4. 自動怜出ず自動構成 +weight: 5 +time: 10 minutes +--- + +このセクションでは、Kubernetes 䞊で実行されおいる Java サヌビスに察しお **自動怜出ず自動構成** を有効にしたす。これにより、OpenTelemetry Collector は Pod のアノテヌションを参照しお、Java アプリケヌションを Splunk OpenTelemetry Java ゚ヌゞェントでむンストルメントすべきかどうかを刀断したす。これによっお、クラスタヌ䞊で実行されおいる Java サヌビスからトレヌス、スパン、プロファむリングデヌタを取埗できるようになりたす。 + +{{% notice title="自動怜出ず自動構成" style="note" %}} + +自動怜出ず自動構成は、**コヌドの倉曎や再コンパむルを必芁ずせずに**、アプリケヌションから **トレヌス、スパン、プロファむリング** デヌタを取埗するこずを目的に蚭蚈されおいる点を理解しおおくこずが重芁です。 + +これは APM を始めるうえで非垞に䟿利な方法ですが、手動むンストルメンテヌションの代替には **なりたせん**。手動むンストルメンテヌションでは、カスタムスパン、タグ、ログをアプリケヌションに远加でき、トレヌスに察しおより倚くのコンテキストず詳现情報を付䞎できたす。 + +{{% /notice %}} + +Java アプリケヌションの堎合、OpenTelemetry Collector はアノテヌション `instrumentation.opentelemetry.io/inject-java` を参照したす。 + +このアノテヌションには、倀ずしお `true` を指定するか、OpenTelemetry Collector の `namespace/daemonset`䟋`default/splunk-otel-collector`を指定できたす。埌者の方匏を䜿うず名前空間をたたいで動䜜させるこずができ、本ワヌクショップではこちらを䜿甚したす。 + +{{% notice title="deployment.yaml の䜿甚" style="info" %}} + +Pod が自動的にトレヌスを送信するようにしたい堎合は、以䞋のように `deployment.yaml` にアノテヌションを远加できたす。これによっお、初回のデプロむ時にむンストルメンテヌションラむブラリが远加されたす。䜜業を効率化するため、以䞋の Pod に぀いおはすでにこの蚭定を行っおいたす: + +- **admin-server** +- **config-server** +- **discovery-server** + +``` yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: admin-server + labels: + app.kubernetes.io/part-of: spring-petclinic +spec: + selector: + matchLabels: + app: admin-server + template: + metadata: + labels: + app: admin-server + annotations: + instrumentation.opentelemetry.io/inject-java: "default/splunk-otel-collector" +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md new file mode 100644 index 0000000000..c7ea769063 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md @@ -0,0 +1,19 @@ +--- +title: APM Service Map +linkTitle: 1. APM Service Map +weight: 1 +--- + +![apm map](../../images/zero-config-first-services-map.png) + +䞊蚘のマップは、すべおのサヌビス間のむンタラクションを瀺しおいたす。PetClinic Microservice アプリケヌションが起動しお完党に同期されるたで数分かかるため、マップはただ䞭間状態である可胜性がありたす。**-2m** ず入力しお時間フィルタヌをカスタム時間 **2 minutes** に短瞮するず芋やすくなりたす。画面右䞊の **Refresh** ボタン **(1)** をクリックしおください。赀い円で瀺される起動時の初期゚ラヌは、最終的に消えおいきたす。 + +次に、request, error, and duration (RED) メトリクスダッシュボヌドを確認するこずで、蚈装された各サヌビスで利甚可胜なメトリクスを調べおみたしょう。 + +この挔習では、サヌビスのオペレヌションで高いレむテンシや゚ラヌが発生しおいる堎合に䜿甚する䞀般的なシナリオを䜿甚したす。 + +Dependency map で **customers-service** をクリックし、**Services** ドロップダりンボックス **(1)** で `customers-service` が遞択されおいるこずを確認したす。次に、Service 名の隣にある Operations ドロップダりン **(2)** から `GET /owners` を遞択したす。 + +これにより、以䞋に瀺すように `GET /owners` でフィルタリングされたワヌクフロヌが衚瀺されたす。 + +![select a trace](../../images/select-workflow.png) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md new file mode 100644 index 0000000000..46317cbde8 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md @@ -0,0 +1,23 @@ +--- +title: APM Trace +linkTitle: 2. APM Trace +weight: 2 +--- + +トレヌスを遞択するには、`Service Requests & Errors` チャヌト内の行を遞択したす **(1)**。関連するトレヌスの䞀芧が衚瀺されたす。 + +関連トレヌスの䞀芧が衚瀺されたら、青色の **(2)** Trace ID リンクをクリックしたす。その際、遞択するトレヌスの Services 列に、これたでに蚀及された 3 ぀のサヌビスが含たれおいるこずを確認しおください。 + +![workflow-trace-pick](../../images/selecting-a-trace.png) + +これにより、遞択したトレヌスが Waterfall ビュヌで衚瀺されたす。 + +ここでは、いく぀かのセクションが確認できたす。 + +* Waterfall ペむン **(1)** では、トレヌスおよび蚈装されたすべおの関数がスパンずしお衚瀺され、その所芁時間や順序・関係性を芖芚的に確認できたす。 +* Trace Info ペむン **(2)** では、遞択したスパンの情報が衚瀺されたすWaterfall ペむン内で察象のスパンが枠で匷調衚瀺されたす。 +* Span ペむン **(3)** では、遞択したスパンに送信されたすべおのタグを確認できたす。䞋にスクロヌルするずすべおのタグを参照できたす。 +* Process ペむンでは、スパンを生成したプロセスに関連するタグが衚瀺されたすスクリヌンショットには含たれおいないため、䞋にスクロヌルしお確認しおください。 +* Trace Properties はペむンの右䞊に䜍眮し、デフォルトでは折りたたたれた状態になっおいたす。 + +![waterfall](../../images/waterfall-view.png) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md new file mode 100644 index 0000000000..f786536056 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md @@ -0,0 +1,46 @@ +--- +title: APM Span +linkTitle: 3. APM Spans +weight: 3 +--- + +スパンを確認しながら、トレヌスに加えお **automatic discovery and configuration** を䜿甚した際に **コヌドを倉曎するこずなく** 利甚できる、いく぀かのアりトオブザボックス機胜を芋おいきたしょう。 + +たず、Waterfall Pane で、以䞋のスクリヌンショットのように `customers-service:SELECT petclinic` たたは類䌌のスパンが遞択されおいるこずを確認しおください。 + +![DB-query](../../images/db-query.png) + +* 基本的なレむテンシヌ情報は、蚈装された関数たたは呌び出しに察するバヌずしお衚瀺されたす。䞊蚘の䟋では、17.8 ミリ秒かかっおいたす。 +* Several similar Spans **(1)** は、スパンが耇数回繰り返されおいる堎合にのみ衚瀺されたす。この䟋では、10 回繰り返されおいたす。`10x` をクリックするず、すべおのスパンを衚瀺非衚瀺にでき、すべおのスパンが順番に衚瀺されたす。 +* **Inferred Services**: 蚈装されおいない倖郚システムぞの呌び出しは、グレヌの「inferred」スパンずしお衚瀺されたす。この䟋における Inferred Service たたはスパンは、䞊蚘の通り Mysql Database ぞの呌び出し `mysql:petclinic SELECT petclinic` **(2)** です。 +* **Span Tags**: Tag Pane では、automatic discovery and configuration によっお生成された暙準的なタグを確認できたす。この堎合、スパンはデヌタベヌスを呌び出しおいるため、`db.statement` タグ **(3)** が含たれおいたす。このタグには DB ク゚リ ステヌトメントが栌玍され、このスパン䞭に実行されたデヌタベヌス呌び出しで䜿甚されたす。これは DB-Query Performance 機胜で利甚されたす。DB-Query Performance に぀いおは次のセクションで芋おいきたす。 +* **Always-on Profiling**: スパンのラむフサむクル䞭にプロファむリング デヌタをキャプチャするようにシステムが蚭定されおいる **堎合**、スパンのタむムラむンにキャプチャされたコヌル スタックの数が衚瀺されたす。䞊蚘の䟋では、`customer-service:GET /owners` スパンに察しお 18 個のコヌル スタックが衚瀺されおいたす。**(4)** + +プロファむリングに぀いおは次のセクションで芋おいきたす。 + + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md new file mode 100644 index 0000000000..bf42dac848 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md @@ -0,0 +1,13 @@ +--- +title: Service Centric View +linkTitle: 4. Service Centric View +weight: 4 +--- + +Splunk APM は **Service Centric Views** を提䟛しおおり、゚ンゞニアはサヌビスのパフォヌマンスを䞀元的なビュヌで深く理解できたす。すべおのサヌビスにわたっお、゚ンゞニアはサヌビスの基盀ずなるむンフラストラクチャから゚ラヌやボトルネックを玠早く特定し、新しいデプロむによるパフォヌマンス䜎䞋をピンポむントで把握し、すべおのサヌドパヌティ䟝存関係の健党性を可芖化できたす。 + +`api-gateway` のこのダッシュボヌドを衚瀺するには、巊偎のメニュヌから **APM** をクリックし、続いおリスト内の `api-gateway` サヌビスをクリックしたす。これにより、Service Centric View ダッシュボヌドが衚瀺されたす。 + +![service_maps](../../images/service-view.png) + +蚈装されたすべおのサヌビスで利甚可胜なこのビュヌでは、**Service metrics**、**Error breakdown**、**Runtime metrics (Java)**、**Infrastructure metrics** の抂芁が確認できたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md new file mode 100644 index 0000000000..5db17e19a5 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md @@ -0,0 +1,13 @@ +--- +title: APM の機胜 +linkTitle: 5. APM の機胜 +weight: 6 +archetype: chapter +time: 15 minutes +--- + +前のセクションで芋おきたように、サヌビス䞊で **automatic discovery and configuration** を有効にするず、トレヌスが **Splunk Observability Cloud** に送信されたす。 + +これらのトレヌスを利甚しお、Splunk は **Service Maps** ず **RED Metrics** を自動的に生成したす。これらはサヌビスの動䜜ず、サヌビス同士がどのように盞互䜜甚しおいるかを理解するための最初のステップです。 + +次のセクションでは、トレヌスそのものず、それが提䟛する情報を詳しく芋おいきたす。コヌドに䞀切手を加えるこずなく、サヌビスの動䜜を理解するのに圹立ちたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md new file mode 100644 index 0000000000..2ef6af8de0 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md @@ -0,0 +1,69 @@ +--- +title: Always-On Profiling & Metrics +linkTitle: 1. Always-On Profiling +weight: 1 +--- + +先ほど Helm chart を䜿っお Splunk Distribution of the OpenTelemetry Collector をむンストヌルした際に、**AlwaysOn Profiling** ず **Metrics** が有効になるよう蚭定したした。これにより、OpenTelemetry Java はアプリケヌションの CPU およびメモリのプロファむリングを自動的に生成し、Splunk Observability Cloud に送信したす。 + +PetClinic アプリケヌションをデプロむしおアノテヌションを蚭定するず、Collector はアプリケヌションを自動怜出し、トレヌスずプロファむリングのためのむンスツルメンテヌションを行いたす。次のスクリプトを実行しお、むンスツルメントしおいる Java コンテナのいずれかの起動ログを確認するこずで、これを怜蚌できたす。 + +ログには、Java の自動怜出ず蚭定で読み蟌たれたフラグが衚瀺されたす。 + +{{< tabs >}} +{{% tab title="Run the script" %}} + +``` logs +. ~/workshop/petclinic/scripts/get_logs.sh +``` + +{{% /tab %}} +{{% tab title="Example output" %}} + +``` text {wrap="false"} +2024/02/15 09:42:00 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s +2024/02/15 09:42:01 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s +2024/02/15 09:42:02 Connected to tcp://discovery-server:8761 +Picked up JAVA_TOOL_OPTIONS: -javaagent:/otel-auto-instrumentation-java/javaagent.jar +Picked up _JAVA_OPTIONS: -Dspring.profiles.active=docker,mysql -Dsplunk.profiler.call.stack.interval=150 +OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended +[otel.javaagent 2024-02-15 09:42:03:056 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-1.30.1-otel-1.32.1 +[otel.javaagent 2024-02-15 09:42:03:768 +0000] [main] INFO com.splunk.javaagent.shaded.io.micrometer.core.instrument.push.PushMeterRegistry - publishing metrics for SignalFxMeterRegistry every 30s +[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - ----------------------- +[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration: +[otel.javaagent 2024-02-15 09:42:07:480 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.enabled : true +[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.directory : /tmp +[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.recording.duration : 20s +[otel.javaagent 2024-02-15 09:42:07:506 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.keep-files : false +[otel.javaagent 2024-02-15 09:42:07:510 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.logs-endpoint : http://10.13.2.38:4317 +[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - otel.exporter.otlp.endpoint : http://10.13.2.38:4317 +[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.enabled : true +[otel.javaagent 2024-02-15 09:42:07:515 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tlab.enabled : true +[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.event.rate : 150/s +[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.call.stack.interval : PT0.15S +[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.include.internal.stacks : false +[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tracing.stacks.only : false +[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - ----------------------- +[otel.javaagent 2024-02-15 09:42:07:518 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active. +``` + +{{% /tab %}} +{{< /tabs >}} +ここで泚目するのは、`com.splunk.opentelemetry.profiler.ConfigurationLogger` によっお出力されおいるセクション、぀たり **Profiling Configuration** の郚分です。 + +`splunk.profiler.directory` のように、制埡可胜なさたざたな蚭定を確認できたす。これは、゚ヌゞェントが Splunk に送信する前にコヌルスタックを曞き蟌む堎所ですコンテナの構成方法によっおは異なる堎合がありたす。 + +倉曎を怜蚎したいもう䞀぀のパラメヌタは `splunk.profiler.call.stack.interval` です。これは、システムが CPU スタックトレヌスをキャプチャする頻床です。Pet Clinic アプリケヌションのような短いスパンがある堎合は、このむンタヌバル蚭定を短くするこずを怜蚎するずよいでしょう。デモアプリケヌションではデフォルトのむンタヌバル倀を倉曎しおいないため、スパンに垞に CPU コヌルスタックが関連付けられおいるずは限りたせん。 + +これらのパラメヌタの蚭定方法は[こちら](https://help.splunk.com/en/splunk-observability-cloud/manage-data/available-data-sources/supported-integrations-in-splunk-observability-cloud/apm-instrumentation/instrument-a-java-application/configure-the-java-agent#profiling-configuration-java)で確認できたす。以䞋の䟋では、`deployment.yaml` の JAVA_OPTIONS 蚭定セクションでこの倀を蚭定するこずにより、コヌルスタックの収集レヌトを高くする方法を瀺しおいたす。 + +``` yaml +env: +- name: JAVA_OPTIONS + value: "-Xdebug -Dsplunk.profiler.call.stack.interval=150" +``` + + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md new file mode 100644 index 0000000000..0cb7615bfb --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md @@ -0,0 +1,32 @@ +--- +title: Always-On Profiling in the Trace Waterfall +linkTitle: 2. Trace Waterfall +weight: 2 +--- + +APM Waterfall ビュヌで元の (たたは類䌌の) Trace ず Span **(1)** を遞択しおいるこずを確認し、右偎のペむンから **Memory Stack Traces (2)** を遞択しおください。 + +![profiling from span](../../images/flamechart-in-waterfall.png) + +ペむンに Memory Stack Trace Flame Graph **(3)** が衚瀺されたす。スクロヌルしたり、ペむンの右端をドラッグしお拡倧したりできたす。 + +AlwaysOn Profiling はアプリケヌションのコヌドのスナップショット (スタックトレヌス) を継続的に取埗しおいたす。䜕千ものスタックトレヌスを読み蟌たなければならないこずを想像しおみおください。これは珟実的ではありたせん。これを支揎するために、AlwaysOn Profiling はプロファむリングデヌタを集玄・サマラむズし、**Flame Graph** ず呌ばれるビュヌで Call Stack を簡単に探玢できるようにしおいたす。これはアプリケヌションから取埗したすべおのスタックトレヌスのサマリヌを衚しおいたす。Flame Graph を䜿甚しお、どのコヌド行がパフォヌマンス問題を匕き起こしおいる可胜性があるかを発芋し、コヌドに加えた倉曎が意図した効果をもたらすかを確認できたす。 + +Always-on Profiling をさらに詳しく調べるには、Profiling ペむンの **Memory Stack Traces** の䞋にある Span **(3)** (䞊蚘画像で参照) を遞択したす。これにより、Memory ビュヌが事前遞択された状態で Always-on Profiling のメむン画面が開きたす。 + +![Profiling main](../../images/profiling-memory.png) + +* Time フィルタヌは、遞択した Span の時間枠に蚭定されたす **(1)** +* Java Memory Metric Charts **(2)** では、`Monitor Heap Memory, Application Activity` ずしお `Memory Allocation Rate` や `Garbage Collecting` などのメトリクスを確認できたす。 +* Span に関連するメトリクスずスタックトレヌスのみにフォヌカス/衚瀺する機胜 **(3)**。これにより、必芁に応じお Java アプリケヌションで実行されおいるバックグラりンドアクティビティをフィルタリングできたす。 +* 識別された Java 関数呌び出し **(4)**。その関数から呌び出されたメ゜ッドにドリルダりンできたす。 +* Flame Graph **(5)**。プロファむル察象サヌビスのスタックトレヌスに基づいた階局を可芖化したす。 +* サヌビスが自身の耇数バヌゞョンを起動する堎合に Service むンスタンスを遞択する機胜 **(6)**。 + +さらなる調査のために、UI ではスタックトレヌスをクリックしお、呌び出された関数ず Flame Chart 内の関連する行を確認できたす。これを䜿えば、コヌディングプラットフォヌム (もちろんお奜みのコヌディングプラットフォヌムによりたす) で実際のコヌド行を衚瀺するこずができたす。 + + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md new file mode 100644 index 0000000000..e7a448f104 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md @@ -0,0 +1,54 @@ +--- +title: Database Query Performance +linkTitle: 3. Database Query Performance +weight: 3 +--- + +Database Query Performance を䜿甚するず、デヌタベヌスク゚リがサヌビスの可甚性に䞎える圱響を Splunk APM で盎接モニタリングできたす。これにより、デヌタベヌスをむンストルメントするこずなく、長時間実行されおいるク゚リ、最適化されおいないク゚リ、重いク゚リを迅速に特定し、それらが匕き起こしおいる可胜性のある問題を軜枛できたす。 + +デヌタベヌスク゚リのパフォヌマンスを確認するには、ブラりザで戻るか、メニュヌバヌの APM セクションに移動しお **Service Map** タむルをクリックし、APM の **Service Map** ペヌゞにいるこずを確認しおください。 + +Dependency map で掚論されたデヌタベヌスサヌビス `mysql:petclinic` Inferred Database server を遞択し **(1)**、右偎のペむンをスクロヌルしお **Database Query Performance** ペむンを芋぀けたす **(2)**。 + +![DB-query from map](../../images/db-query-map.png) + +マップで遞択したサヌビスが実際に掚論されたデヌタベヌスサヌバヌである堎合、このペむンは継続時間に基づく䞊䜍 90%P90のデヌタベヌス呌び出しで埋められたす。db-query performance 機胜をさらに深く掘り䞋げるには、ペむン䞊郚の **Database Query Performance** ずいう単語のあたりをクリックしたす。 + +これにより、DB-query Performance 抂芁画面が衚瀺されたす。 + +![DB-query full](../../images/db-query-full.png) + +{{% notice title="Database Query Normalization" style="info" %}} +デフォルトでは、Splunk APM のむンストルメンテヌションは、シヌクレットや個人を特定できる情報PIIなどの機密デヌタを `db.statements` から削陀たたはマスクするためにデヌタベヌスク゚リをサニタむズしたす。デヌタベヌスク゚リの正芏化を無効にする方法は[こちら](https://help.splunk.com/en/splunk-observability-cloud/monitor-application-performance/monitor-database-query-performance/troubleshoot-database-query-performance#turn-off-database-query-normalization)で確認できたす。 +{{% /notice %}} + +この画面では、Splunk Observability Cloud に送信された Traces ず Spans に基づいお、アプリケヌションからデヌタベヌスに察しお行われたすべおのデヌタベヌスク゚リ **(1)** が衚瀺されたす。時間ブロック間で比范したり、Total Time、P90 Latency、Requests で゜ヌトしたりできるこずに泚意しおください **(2)**。 + +リスト内の各デヌタベヌスク゚リに぀いお、最も高いレむテンシヌ、時間枠内の総呌び出し回数、1 秒あたりのリク゚スト数が衚瀺されたす **(3)**。これにより、ク゚リを最適化できる箇所を特定できたす。 + +右偎のペむンの 2 ぀のチャヌト **(5)** を介しお、デヌタベヌス呌び出しを含むトレヌスを遞択できたす。Tag Spotlight ペむン **(6)** を䜿甚しお、゚ンドポむントやタグに基づいお、デヌタベヌス呌び出しに関連するタグを掘り䞋げお確認したす。 + +ク゚リの詳现ビュヌを確認する必芁がある堎合は、次のずおりです。 + +![details](../../images/query-details.png) + +特定のク゚リをクリックしたす **(1)**。これにより、Query Details ペむン **(2)** が開き、より詳现な調査に䜿甚できたす。 + + diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md new file mode 100644 index 0000000000..72d08541a2 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md @@ -0,0 +1,16 @@ +--- +title: Always-On Profiling & DB Query Performance +linkTitle: 6. Advanced Features +weight: 7 +archetype: chapter +time: 15 minutes +--- + +前章で芋おきたように、APM を䜿えばコヌドに手を加えるこずなく各サヌビス間のやり取りをトレヌスでき、問題をより迅速に特定できたす。 + +トレヌスに加えお、**自動怜出ず構成** はすぐに䜿える远加機胜を提䟛しおおり、問題をさらに玠早く発芋するのに圹立ちたす。本セクションでは、その䞭から次の 2 ぀を取り䞊げたす。 + +- **Always-on Profiling ず Java メトリクス** +- **Database Query Performance** + +Always-on Profiling や DB-Query Performance に぀いおさらに深く孊びたい堎合は、別の Ninja Workshop である [**Debug Problems in Microservices**](/en/scenarios/debug_problems/) を参照しおください。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md new file mode 100644 index 0000000000..03904e6319 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md @@ -0,0 +1,21 @@ +--- +title: ログの衚瀺 +linkTitle: 1. ログの衚瀺 +weight: 2 +--- + +ログを確認するには、巊偎のメニュヌから ![Logo](../images/logo-icon.png?classes=inline&height=25px) **Log Observer** をクリックしたす。Log Observer に入ったら、フィルタヌバヌの **Index** が **splunk4rookies-workshop** に蚭定されおいるこずを確認しおください。**(1)** + +次に、**Add Filter** をクリックし、*Fields* **(2)** オプションを䜿っおフィヌルド `deployment.environment` **(3)** を怜玢したす。続いお、ドロップダりンリストから自分のワヌクショップむンスタンスを遞択し **(4)**、`=`含めるをクリックしたす。これで、PetClinic アプリケヌションからのログメッセヌゞのみが衚瀺されるようになりたす。 + +![Log Observer sort](../../images/log-observer-sort.png) + +次に、フィヌルド `service.name` を怜玢し、倀 `customers-service` を遞択しお `=`含めるをクリックしたす。これがフィルタヌバヌに衚瀺されるはずです **(1)**。続いお **Run Search** ボタン **(2)** をクリックしたす。 + +![Log Observer run](../../images/log-observer-run.png) + +これによりログ゚ントリが曎新され、`customers-service` のみの゚ントリに絞り蟌たれお衚瀺されたす。 + +![Log Observer](../../images/log-observer-trace-info.png) + +*"Saving pet"* で始たる゚ントリをクリックしたす **(1)**。サむドペむンが開き、関連するトレヌス ID およびスパン ID を含む詳现情報を確認できたす **(2)**。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md new file mode 100644 index 0000000000..52d99d2a4a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md @@ -0,0 +1,15 @@ +--- +title: Related Content +linkTitle: 2. Related Content +weight: 3 +--- + +䞋郚のペむンには、関連するコンテンツが衚瀺されたす。次のスクリヌンショットでは、APM がこのログ行に関連するトレヌスを怜出しおいるこずが確認できたす **(1)**。 + +![RC](../../images/log-apm-rc.png) + +**Trace for 960432ac9f16b98be84618778905af50** を **(2)** クリックするず、このログ行が生成された特定のトレヌスの APM 内のりォヌタヌフォヌル画面に移動したす。 + +![waterfall logs](../../images/waterfall-with-logs.png) + +ここで、Logs 甚の **Related Content** ペむンが衚瀺されおいる **(1)** こずに泚目しおください。これをクリックするず Log Observer に戻り、このトレヌスに含たれるすべおのログ行が衚瀺されたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md new file mode 100644 index 0000000000..5b59805b07 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md @@ -0,0 +1,17 @@ +--- +title: Log Observer +linkTitle: 7. Log Observer +weight: 8 +archetype: chapter +time: 10 minutes +--- + +ここたでの工皋では**コヌドの倉曎は䞀切行っおいたせん**が、トレヌス、プロファむリング、Database Query Performance のデヌタが Splunk Observability Cloud に送信されおいたす。 + +次は **Splunk Log Observer** を䜿っお、Spring PetClinic アプリケヌションからログデヌタを取埗したす。 + +**Splunk OpenTelemetry Collector** は Spring PetClinic アプリケヌションからログを自動的に収集し、OTLP exporter を䜿っお Splunk Observability Cloud に送信したす。その際、ログむベントには `trace_id`、`span_id`、トレヌスフラグが付䞎されたす。 + +そしお **Splunk Log Observer** を䜿っおログを衚瀺し、ログ情報をサヌビスやトレヌスず自動的に盞関付けしたす。 + +この機胜は [**Related Content**](https://help.splunk.com/en/splunk-observability-cloud/data-tools/related-content) ず呌ばれたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md new file mode 100644 index 0000000000..390a42d039 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md @@ -0,0 +1,22 @@ +--- +title: Petclinic アプリの RUM ビュヌを遞択する +linkTitle: 1. RUM デヌタを確認する +weight: 1 +--- + +たずは RUM の抂芁をざっず芋おいきたしょう。巊偎のメニュヌから **RUM** をクリックしおください。次に **Environment** フィルタヌ **(1)** を、ドロップダりンボックスからワヌクショップむンスタンスの名前に倉曎し、**`-workshop`** **(1)** を遞択したす**`INSTANCE`** は先ほど実行したシェルスクリプトの倀です。これだけが遞択されおいる状態にしおください。 + +続いお、**App** **(2)** ドロップダりンボックスをアプリの名前**`-store`**に倉曎したす。 + +![rum select](../../images/rum-env-select.png) + +**Environment** ず **App** を遞択するず、アプリケヌションの RUM ステヌタスを瀺す抂芁ペヌゞが衚瀺されたす。Summary Dashboard が数倀の 1 行だけになっおいる堎合は、瞮小衚瀺の状態です。アプリケヌション名の前にある **> (1)** をクリックしお展開できたす。JavaScript ゚ラヌが発生しおいた堎合は、以䞋のように衚瀺されたす。 + +![rum overview](../../images/rum-overview.png) + +続けるには、青いリンクワヌクショップ名が衚瀺されおいるものをクリックしお詳现ペヌゞに移動したす。するず、UX Metrics、Front-end Health、Back-end Health、Custom Events ごずにむンタラクションを分解し、過去のメトリクスデフォルトでは 1 時間ず比范する新しいダッシュボヌドビュヌが衚瀺されたす。 + +![rum main](../../images/rum-main.png) +通垞、最初のチャヌトには 1 本の線だけが衚瀺されたす。Petclinic ショップに関連するリンクをクリックしおください。この䟋では です。 + +これにより、Tag Spotlight ペヌゞに移動したす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md new file mode 100644 index 0000000000..e998b650d6 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md @@ -0,0 +1,14 @@ +--- +title: RUMトレヌスのりォヌタヌフォヌルビュヌずAPMぞのリンク +linkTitle: 2. RUMトレヌスをたどる +weight: 2 +--- +TAG Spotlightビュヌでは、RUMデヌタに関連付けられたすべおのタグが衚瀺されたす。タグは、デヌタを識別するために䜿甚されるキヌず倀のペアです。今回の堎合、タグはOpenTelemetryのむンストルメンテヌションによっお自動的に生成されおいたす。タグは、デヌタをフィルタリングしたり、チャヌトやテヌブルを䜜成するために䜿甚されたす。Tag Spotlightビュヌでは、挙動のトレンドを怜出し、ナヌザヌセッションをドリルダりンしお調査できたす。 + +![RUM TAG](../../images/rum-tag-spotlight.png) + +User Sessions **(1)** をクリックするず、その時間垯に発生したナヌザヌセッションの䞀芧が衚瀺されたす。 + +そのうちの1぀を確認したいので、*Duration* **(2)** をクリックしお所芁時間で゜ヌトし、所芁時間が長いセッションのいずれかのリンク **(3)** をクリックしおください。 + +![User sessions](../../images/rum-user-sessions.png) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md new file mode 100644 index 0000000000..91228941ef --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md @@ -0,0 +1,19 @@ +--- +title: RUMトレヌスりォヌタヌフォヌルビュヌずAPMぞのリンク +linkTitle: 3. RUMりォヌタヌフォヌル +weight: 3 +--- + +ここではRUMトレヌスりォヌタヌフォヌルを芋おいたす。これにより、ナヌザヌがpetclinicアプリケヌションのペヌゞを蚪問した際に、ナヌザヌのデバむス䞊でセッション䞭に䜕が起こったかを確認できたす。 + +りォヌタヌフォヌルを䞋にスクロヌルしお右偎の **#!/owners/details** セグメント **(1)** をクリックするず、Vetsリク゚ストの凊理䞭に発生したアクションのリストが衚瀺されたす。HTTPリク゚ストには、リタヌンコヌドの前に青色の **APM** リンクが衚瀺されおいるこずに泚目しおください。いずれか1぀を遞び、APMリンクをクリックしたす。これにより、Kubernetes䞊でホストされおいるこのバック゚ンドサヌビス呌び出しのAPM情報が衚瀺されたす。 + +![rum apm link](../../images/rum-trace.png) + +リク゚ストで䜕が起こったかをドリルダりンしお確認したい堎合は、Trace IDのURLをクリックしおください。 + +これにより、RUMからのリク゚ストに関連するトレヌスが衚瀺されたす: + +![RUm-apm linked](../../images/rum-apm-waterfall.png) + +サヌビスぞの゚ントリポむントに **RUM (1)** 関連のコンテンツリンクが远加され、バック゚ンドサヌビスで䜕が起こったかを怜蚌した埌にRUMセッションぞ戻れるようになっおいるこずがわかりたす。 diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md new file mode 100644 index 0000000000..7b964c115a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md @@ -0,0 +1,53 @@ +--- +title: Real User Monitoring +linkTitle: 8. Real User Monitoring +weight: 9 +time: 10 minutes +archetype: chapter +--- + +アプリケヌションに察しお Real User Monitoring (RUM) のむンストルメンテヌションを有効化するには、Open Telemetry Javascript の [**https://github.com/signalfx/splunk-otel-js-web**](https://github.com/signalfx/splunk-otel-js-web) スニペットをコヌドベヌスに远加する必芁がありたす。 + +Spring PetClinic アプリケヌションは、アプリケヌションのすべおのビュヌで再利甚される単䞀の [**index**](https://github.com/spring-petclinic/spring-petclinic-microservices/blob/main/spring-petclinic-api-gateway/src/main/resources/static/index.html) HTML ペヌゞを䜿甚しおいたす。このペヌゞは、すべおのペヌゞで自動的に読み蟌たれるため、Splunk RUM むンストルメンテヌションラむブラリを挿入するのに最適な堎所です。 + +`api-gateway` サヌビスではすでにむンストルメンテヌションが動䜜しおおり、RUM トレヌスを Splunk Observability Cloud に送信しおいたす。次のセクションでこのデヌタを確認したす。 + +スニペットを確認したい堎合は、ブラりザでペヌゞを右クリックし、**View Page Source** を遞択しおペヌゞ゜ヌスを衚瀺できたす。 + +``` html + + + + + +``` diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md new file mode 100644 index 0000000000..d6927c6599 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md @@ -0,0 +1,17 @@ +--- +title: ワヌクショップのたずめ 🎁 +linkTitle: 9. ワヌクショップのたずめ +weight: 9 +archetype: chapter +description: おめでずうございたす、Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry を完了したした。本日は、Kubernetes 䞊の既存の Java アプリケヌションに Tracing、Code Profiling、Database Query Performance を远加しお、アプリケヌションずむンフラストラクチャのオブザヌバビリティを即座に向䞊させる方法がいかに簡単かを孊びたした。 +--- + +おめでずうございたす、**Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry** ワヌクショップを完了したした。 + +本日は、Kubernetes 䞊の既存の Java アプリケヌションに Tracing、Code Profiling、Database Query Performance を远加するこずがいかに簡単かを孊びたした。 + +**Automatic Discovery and Configuration** を䜿甚するこずで、コヌドや蚭定を䞀行も倉曎するこずなく、アプリケヌションずむンフラストラクチャのオブザヌバビリティを即座に向䞊させるこずができたした。 + +たた、シンプルな蚭定倉曎だけで、゚ンドツヌ゚ンドのオブザヌバビリティを実珟するために、アプリケヌションにさらに倚くのオブザヌバビリティ**logging** ず **RUM**を远加できるこずも孊びたした。 + +![Champagne](images/champagne.png?width=45vw) diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md new file mode 100644 index 0000000000..b69c7a1b50 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md @@ -0,0 +1,32 @@ +--- +title: Spring PetClinic SpringBoot Based Microservices On Kubernetes +linkTitle: PetClinic Kubernetes Workshop +weight: 2 +archetype: chapter +authors: ["Pieter Hagen"] +description: Kubernetes 䞊で皌働する Java ベヌスのアプリケヌションに察しお、自動怜出ず自動蚭定を有効化する方法を孊びたす。゚ンドツヌ゚ンドの可芖性によりアプリケヌションの動䜜を最倧限に把握できる、リアルタむム監芖を䜓隓しおください。 +time: 90 minutes +--- + +このワヌクショップの目的は、Java 向けの Splunk の **automatic discovery and configuration**自動怜出ず自動蚭定の機胜を玹介するこずです。 + +ワヌクショップのシナリオは、シンプルな**蚈装されおいない**Java マむクロサヌビスアプリケヌションを Kubernetes にむンストヌルしお構築したす。 + +既存の Java ベヌスのデプロむメントに察しお自動怜出機胜付きの Splunk OpenTelemetry Collector をむンストヌルするシンプルな手順に埓うこずで、メトリクス、トレヌス、ログを **Splunk Observability Cloud** ぞ送信するこずがいかに簡単であるかを確認したす。 + +> [!SPLUNK]前提条件 +> +> * ポヌト **2222** ぞのアりトバりンド SSH アクセス。 +> * ポヌト **81** ぞのアりトバりンド HTTP アクセス。 +> * Linux コマンドラむンの基本的な知識。 + +このワヌクショップでは、以䞋のコンポヌネントを取り䞊げたす。 + +* Splunk Infrastructure Monitoring (**IM**) +* Splunk automatic discovery and configuration for Java (**APM**) + * Database Query Performance + * AlwaysOn Profiling +* Splunk Log Observer (**LO**) +* Splunk Real User Monitoring (**RUM**) + +_Splunk Synthetics は今回少し蚊垳の倖ですが、他のワヌクショップでカバヌしおいたす_ {{% icon icon="heart" %}} diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md new file mode 100644 index 0000000000..fd3957ac97 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md @@ -0,0 +1,9 @@ +--- +title: Automatic Discovery ワヌクショップ +description: れロコヌドでの Java むンスツルメンテヌションの実䟋 — モノリスおよび Kubernetes 環境におけるサヌビスの自動怜出ず、メトリクス、トレヌス、ログの送信を䜓隓したす。 +weight: 1 +time: 60 minutes +aliases: + - /ninja-workshops/1-automatic-discovery/ +layout: "hero" +--- diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md new file mode 100644 index 0000000000..95e6549d21 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md @@ -0,0 +1,310 @@ +--- +title: Installing OpenTelemetry Collector Contrib +linkTitle: 1.1 Confirm Installation +weight: 1 +--- + +## Collector が動䜜しおいるこずを確認する + +Collector は珟圚動䜜しおいるはずです。`systemctl` コマンドを䜿っお root 暩限で確認したす。ステヌタス衚瀺を終了するには `q` を抌すだけです。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo systemctl status otelcol-contrib +``` + +{{% /tab %}} +{{% tab title="Status Output" %}} + +``` text +● otelcol-contrib.service - OpenTelemetry Collector Contrib + Loaded: loaded (/lib/systemd/system/otelcol-contrib.service; enabled; vendor preset: enabled) + Active: active (running) since Mon 2024-10-07 10:27:49 BST; 52s ago + Main PID: 17113 (otelcol-contrib) + Tasks: 13 (limit: 19238) + Memory: 34.8M + CPU: 155ms + CGroup: /system.slice/otelcol-contrib.service + └─17113 /usr/bin/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml + +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Descriptor: +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Name: up +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Description: The scraping was successful +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Unit: +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> DataType: Gauge +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: NumberDataPoints #0 +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: StartTimestamp: 1970-01-01 00:00:00 +0000 UTC +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Timestamp: 2024-10-07 09:28:36.942 +0000 UTC +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Value: 1.000000 +Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: {"kind": "exporter", "data_type": "metrics", "name": "debug"} +``` + +{{% /tab %}} +{{< /tabs >}} + +これから耇数の蚭定ファむルの倉曎や環境倉数の蚭定、Collector の再起動を行うため、Collector サヌビスを停止し、起動時に自動起動しないように無効化したす。 + +{{< tabs >}} +{{% tab title="Command" %}} + +``` bash +sudo systemctl stop otelcol-contrib && sudo systemctl disable otelcol-contrib +``` + +{{% /tab %}} +{{< /tabs >}} + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Open Telemetry Collector Builder (ocb) を䜿っお独自の Collector をビルドする{{% /badge %}}" %}} +このパヌトでは、システムに以䞋のものがむンストヌルされおいる必芁がありたす。 + +- Golang (最新バヌゞョン) + + ``` bash + cd /tmp + wget https://golang.org/dl/go1.20.linux-amd64.tar.gz + sudo tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz + ``` + + `.profile` を線集し、以䞋の環境倉数を远加したす。 + + ``` bash + export GOROOT=/usr/local/go + export GOPATH=$HOME/go + export PATH=$GOPATH/bin:$GOROOT/bin:$PATH + ``` + + シェルセッションを曎新したす。 + + ``` bash + source ~/.profile + ``` + + Go のバヌゞョンを確認したす。 + + ``` bash + go version + ``` + +- ocb のむンストヌル + - [project releases](https://github.com/open-telemetry/opentelemetry-collector/releases/tag/cmd%2Fbuilder%2Fv0.80.0) から ocb バむナリをダりンロヌドし、以䞋のコマンドを実行したす。 + + ```bash + mv ocb_0.80.0_darwin_arm64 /usr/bin/ocb + chmod 755 /usr/bin/ocb + ``` + + 別のアプロヌチずしお、golang のツヌルチェむンを䜿っおバむナリをロヌカルでビルドする方法もありたす。 + + ```bash + go install go.opentelemetry.io/collector/cmd/builder@v0.80.0 + mv $(go env GOPATH)/bin/builder /usr/bin/ocb + ``` + +- (オプション) Docker + +## なぜ独自の Collector をビルドするのか? + +Collector のデフォルトのディストリビュヌション (core および contrib) は、提䟛されおいる内容が倚すぎるか、少なすぎるかのいずれかになりがちです。 + +たた、contrib Collector は、デプロむで必芁ずしない可胜性が高いコンポヌネントが倚数むンストヌルされおいるため、本番環境での実行は掚奚されたせん。 + +## 独自の Collector をビルドするメリット + +独自の Collector バむナリ (䞀般的にディストリビュヌションず呌ばれたす) を䜜成するこずは、必芁なものだけをビルドするこずを意味したす。 + +メリットは以䞋のずおりです。 + +1. バむナリサむズが小さくなる +2. 既存の Go の脆匱性スキャナヌを䜿甚できる +3. 組織ず連携できる内郚コンポヌネントを含めるこずができる + +## 独自の Collector をビルドする際の考慮事項 + +さお、🥷 Ninja ゟヌンず呌ばれるからには、いく぀かの欠点もありたす。 + +1. Go の経隓は必須ではないが掚奚される +1. Splunk のサポヌトは**ありたせん** +1. 配垃ずラむフサむクル管理の責任が生じる + +プロゞェクトは安定化に向けお取り組んでいたすが、倉曎によっおワヌクフロヌが壊れないずいう保蚌はないこずに泚意しおください。Splunk のチヌムは、より手厚いサポヌトず高い安定性を提䟛しおおり、デプロむのニヌズに応じおキュレヌションされた゚クスペリ゚ンスを提䟛できたす。 + +## The Ninja Zone + +開始するために必芁なツヌルがすべおむンストヌルされたら、`otelcol-builder.yaml` ずいう名前の新しいファむルを䜜成し、以䞋のディレクトリ構造に埓う必芁がありたす。 + +``` bash +. +└── otelcol-builder.yaml +``` + +ファむルを䜜成したら、远加のメタデヌタずずもにむンストヌルするコンポヌネントのリストを远加する必芁がありたす。 + +この䟋では、introduction の蚭定で必芁なコンポヌネントのみをむンストヌルするビルダヌマニフェストを䜜成したす。 + +```yaml +dist: + name: otelcol-ninja + description: A custom build of the Open Telemetry Collector + output_path: ./dist + +extensions: +- gomod: go.opentelemetry.io/collector/extension/ballastextension v0.80.0 +- gomod: go.opentelemetry.io/collector/extension/zpagesextension v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/httpforwarder v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0 + +exporters: +- gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0 +- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/splunkhecexporter v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/signalfxexporter v0.80.0 + +processors: +- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0 +- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.80.0 + +receivers: +- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0 +- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/zipkinreceiver v0.80.0 +``` + +_ocb_ 甚の yaml ファむルを曎新したら、以䞋のコマンドを実行したす。 + +```shell +ocb --config=otelcol-builder.yaml +``` + +実行するず、以䞋のディレクトリ構造になりたす。 + +``` text +├── dist +│ ├── components.go +│ ├── components_test.go +│ ├── go.mod +│ ├── go.sum +│ ├── main.go +│ ├── main_others.go +│ ├── main_windows.go +│ └── otelcol-ninja +└── otelcol-builder.yaml +``` + +### References + +1. [https://opentelemetry.io/docs/collector/custom-collector/](https://opentelemetry.io/docs/collector/custom-collector/) + +{{% /expand %}} + +--- + +## デフォルトの蚭定 + +OpenTelemetry は YAML ファむルを通じお蚭定されたす。これらのファむルにはデフォルトの蚭定があり、ニヌズに合わせお倉曎できたす。提䟛されおいるデフォルトの蚭定を芋おみたしょう。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +cat /etc/otelcol-contrib/config.yaml +``` + +{{% /tab %}} +{{% tab title="config.yaml" %}} + +```yaml { lineNos="table" wrap="true"} +# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface. +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + +exporters: + debug: + verbosity: detailed + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{< /tabs >}} + +おめでずうございたす! OpenTelemetry Collector のダりンロヌドずむンストヌルに成功したした。OTel Ninja ぞの道のりは順調です。しかし、その前に、蚭定ファむルず OpenTelemetry Collector のさたざたなディストリビュヌションに぀いお芋おいきたしょう。 + +{{% notice style="note" %}} + +Splunk は、完党にサポヌトされた独自の OpenTelemetry Collector ディストリビュヌションを提䟛しおいたす。このディストリビュヌションは、[**Splunk GitHub Repository**](https://github.com/signalfx/splunk-otel-collector) からむンストヌルできるほか、Splunk Observability Cloud のりィザヌドを䜿っおシンプルなむンストヌルスクリプトをコピヌ&ペヌストする圢でも利甚できたす。このディストリビュヌションには、OpenTelemetry Collector Contrib ディストリビュヌションでは利甚できない倚くの远加機胜ず拡匵機胜が含たれおいたす。 + +- Splunk Distribution of the OpenTelemetry Collector は本番環境でテスト枈みです。倚くのお客様が本番環境で䜿甚しおいたす。 +- 圓瀟のディストリビュヌションを利甚するお客様は、SLA の範囲内で公匏の Splunk サポヌトから盎接支揎を受けられたす。 +- お客様は、メトリクスずトレヌス収集に関するコア蚭定゚クスペリ゚ンスにおける将来の砎壊的倉曎を心配するこずなく、Splunk Distribution of the OpenTelemetry Collector を䜿甚たたは移行できたす (OpenTelemetry のログ収集蚭定はベヌタ版です)。Collector のメトリクスに぀いおは砎壊的倉曎がある可胜性がありたす。 + +{{% /notice %}} + +これから蚭定ファむルの各セクションを順に芋おいき、ホストメトリクスを Splunk Observability Cloud に送信するように倉曎したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md new file mode 100644 index 0000000000..e95aad38d3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md @@ -0,0 +1,41 @@ +--- +title: OpenTelemetry Collector Contrib のむンストヌル +linkTitle: 1. むンストヌル +weight: 1 +--- + +## OpenTelemetry Collector Contrib ディストリビュヌションのダりンロヌド + +OpenTelemetry Collector をむンストヌルする最初のステップは、ダりンロヌドするこずです。本ラボでは、`wget` コマンドを䜿甚しお OpenTelemetry の GitHub リポゞトリから `.deb` パッケヌゞをダりンロヌドしたす。 + +お䜿いのプラットフォヌム向けの `.deb` パッケヌゞを [**OpenTelemetry Collector Contrib releases page**](https://github.com/open-telemetry/opentelemetry-collector-releases/releases) から取埗しおください。 + +``` bash +wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.111.0/otelcol-contrib_0.111.0_linux_amd64.deb +``` + +## OpenTelemetry Collector Contrib ディストリビュヌションのむンストヌル + +`dpkg` を䜿甚しお `.deb` パッケヌゞをむンストヌルしたす。むンストヌルが成功した際の出力䟋に぀いおは、䞋蚘の **dpkg Output** タブをご確認ください。 + +{{< tabs >}} +{{% tab title="Install" %}} + +``` bash +sudo dpkg -i otelcol-contrib_0.111.0_linux_amd64.deb +``` + +{{% /tab %}} +{{% tab title="dpkg Output" %}} + +``` text +Selecting previously unselected package otelcol-contrib. +(Reading database ... 89232 files and directories currently installed.) +Preparing to unpack otelcol-contrib_0.111.0_linux_amd64.deb ... +Unpacking otelcol-contrib (0.111.0) ... +Setting up otelcol-contrib (0.111.0) ... +Created symlink /etc/systemd/system/multi-user.target.wants/otelcol-contrib.service → /lib/systemd/system/otelcol-contrib.service. +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md new file mode 100644 index 0000000000..349b38802f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md @@ -0,0 +1,58 @@ +--- +title: OpenTelemetry Collector Extensions +linkTitle: 2.1 Health Check +weight: 1 +--- + +## Health Check + +Extensions は、むンストヌル手順で参照したのず同じ `config.yaml` ファむル内で構成したす。`config.yaml` ファむルを線集しお Extensions を構成したしょう。なお、**pprof** および **zpages** Extension はデフォルトの `config.yaml` ファむルですでに構成されおいたす。このワヌクショップでは、Collector のヘルス状態にアクセスできるポヌトをすべおのネットワヌクむンタヌフェヌスで公開するため、**health_check** Extension のみを曎新したす。 + +{{% tab title="Command" %}} + +``` bash +sudo vi /etc/otelcol-contrib/config.yaml +``` + +{{% /tab %}} + +{{% tab title="Extensions Configuration" %}} + +```yaml {hl_lines="3"} +extensions: + health_check: + endpoint: 0.0.0.0:13133 +``` + +{{% /tab %}} + +Collector を起動したす: + +{{% tab title="Command" %}} + +``` bash +otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml +``` + +{{% /tab %}} + +この Extension は、OpenTelemetry Collector のステヌタスをチェックするためにプロヌブできる HTTP URL を有効化したす。この Extension は、Kubernetes の liveness プロヌブや readiness プロヌブずしおも䜿甚できたす。`curl` コマンドの詳现に぀いおは、[curl man page](https://curl.se/docs/manpage.html) を参照しおください。 + +新しいタヌミナルセッションを開いおむンスタンスに SSH 接続し、次のコマンドを実行したす: + +{{< tabs >}} +{{% tab title="curl Command" %}} + +```bash +curl http://localhost:13133 +``` + +{{% /tab %}} +{{% tab title="curl Output" %}} + +``` text +{"status":"Server available","upSince":"2024-10-07T11:00:08.004685295+01:00","uptime":"12.56420005s"} +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md new file mode 100644 index 0000000000..9e104197f8 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md @@ -0,0 +1,9 @@ +--- +title: OpenTelemetry Collector Extensions +linkTitle: 2.2 Performance Profiler +weight: 2 +--- + +## Performance Profiler + +[**Performance Profiler**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/extension/pprofextension/README.md) extension は、golang net/http/pprof ゚ンドポむントを有効にしたす。これは通垞、開発者がパフォヌマンスプロファむルを収集し、サヌビスの問題を調査するために䜿甚されたす。**このワヌクショップでは扱いたせん**。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md new file mode 100644 index 0000000000..83c8df6784 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md @@ -0,0 +1,363 @@ +--- +title: OpenTelemetry Collector Extensions +linkTitle: 2.3 zPages +weight: 3 +--- + +## zPages + +[**zPages**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/extension/zpagesextension/README.md) は、倖郚 exporter の代替ずなるむンプロセスの仕組みです。有効化するず、トレヌスずメトリクスの情報をバックグラりンドで収集および集玄し、リク゚ストに応じお Web ペヌゞずしお提䟛したす。zPages は Collector が想定どおりに動䜜しおいるこずを確認するうえで非垞に有甚な蚺断機胜です。 + +{{< tabs >}} +{{% tab title="ServiceZ" %}} + +**ServiceZ** は Collector のサヌビス抂芁を提䟛し、pipelinez、extensionz、featurez の各 zPages ぞすばやくアクセスできるようにしたす。このペヌゞではビルド情報やランタむム情報も確認できたす。 + +URL の䟋: [**http://localhost:55679/debug/servicez**](http://localhost:55679/debug/servicez) `localhost` は実際の環境に合わせお倉曎しおください。 + +![ServiceZ](../../images/servicez.png) + +{{% /tab %}} +{{% tab title="PipelineZ" %}} + +**PipelineZ** は Collector で皌働䞭のパむプラむンに関する情報を提䟛したす。タむプ、デヌタが倉換されるかどうか、各パむプラむンで利甚されおいる receiver、processor、exporter の情報を確認できたす。 + +URL の䟋: [**http://localhost:55679/debug/pipelinez**](http://localhost:55679/debug/pipelinez) `localhost` は実際の環境に合わせお倉曎しおください。 + +![PipelineZ](../../images/pipelinez.png) + +{{% /tab %}} +{{% tab title="ExtensionZ" %}} + +**ExtensionZ** は Collector でアクティブになっおいる extension を衚瀺したす。 + +URL の䟋: [**http://localhost:55679/debug/extensionz**](http://localhost:55679/debug/extensionz) `localhost` は実際の環境に合わせお倉曎しおください。 + +![ExtensionZ](../../images/extensionz.png) + +{{% /tab %}} +{{% /tabs %}} + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** storage extension でデヌタの耐久性を高める{{% /badge %}}" %}} + +これを行うには、利甚しおいるディストリビュヌションに `file_storage` extension がむンストヌルされおいるこずを確認する必芁がありたす。これは `otelcol-contrib components` コマンドを実行するこずで確認でき、次のような結果が衚瀺されたす。 + +{{< tabs >}} +{{% tab title="Truncated Output" %}} + +```yaml +# ... truncated for clarity +extensions: + - file_storage +``` + +{{% /tab %}} +{{% tab title="Full Output" %}} + +```yaml +buildinfo: + command: otelcol-contrib + description: OpenTelemetry Collector Contrib + version: 0.80.0 +receivers: + - prometheus_simple + - apache + - influxdb + - purefa + - purefb + - receiver_creator + - mongodbatlas + - vcenter + - snmp + - expvar + - jmx + - kafka + - skywalking + - udplog + - carbon + - kafkametrics + - memcached + - prometheus + - windowseventlog + - zookeeper + - otlp + - awsecscontainermetrics + - iis + - mysql + - nsxt + - aerospike + - elasticsearch + - httpcheck + - k8sobjects + - mongodb + - hostmetrics + - signalfx + - statsd + - awsxray + - cloudfoundry + - collectd + - couchdb + - kubeletstats + - jaeger + - journald + - riak + - splunk_hec + - active_directory_ds + - awscloudwatch + - sqlquery + - windowsperfcounters + - flinkmetrics + - googlecloudpubsub + - podman_stats + - wavefront + - k8s_events + - postgresql + - rabbitmq + - sapm + - sqlserver + - redis + - solace + - tcplog + - awscontainerinsightreceiver + - awsfirehose + - bigip + - filelog + - googlecloudspanner + - cloudflare + - docker_stats + - k8s_cluster + - pulsar + - zipkin + - nginx + - opencensus + - azureeventhub + - datadog + - fluentforward + - otlpjsonfile + - syslog +processors: + - resource + - batch + - cumulativetodelta + - groupbyattrs + - groupbytrace + - k8sattributes + - experimental_metricsgeneration + - metricstransform + - routing + - attributes + - datadog + - deltatorate + - spanmetrics + - span + - memory_limiter + - redaction + - resourcedetection + - servicegraph + - transform + - filter + - probabilistic_sampler + - tail_sampling +exporters: + - otlp + - carbon + - datadog + - f5cloud + - kafka + - mezmo + - skywalking + - awsxray + - dynatrace + - loki + - prometheus + - logging + - azuredataexplorer + - azuremonitor + - instana + - jaeger + - loadbalancing + - sentry + - splunk_hec + - tanzuobservability + - zipkin + - alibabacloud_logservice + - clickhouse + - file + - googlecloud + - prometheusremotewrite + - awscloudwatchlogs + - googlecloudpubsub + - jaeger_thrift + - logzio + - sapm + - sumologic + - otlphttp + - googlemanagedprometheus + - opencensus + - awskinesis + - coralogix + - influxdb + - logicmonitor + - signalfx + - tencentcloud_logservice + - awsemf + - elasticsearch + - pulsar +extensions: + - zpages + - bearertokenauth + - oidc + - host_observer + - sigv4auth + - file_storage + - memory_ballast + - health_check + - oauth2client + - awsproxy + - http_forwarder + - jaegerremotesampling + - k8s_observer + - pprof + - asapclient + - basicauth + - headers_setter +``` + +{{% /tab %}} +{{< /tabs >}} + +この extension は、exporter が蚭定枈みの゚ンドポむントぞデヌタを送信できない堎合に、ディスクぞデヌタをキュヌむングする機胜を提䟛したす。 + +この extension を構成するには、以䞋の情報を含むように蚭定を曎新する必芁がありたす。最初に /tmp/otel-data ディレクトリを䜜成し、読み曞き暩限を付䞎しおください。 + +```yaml +extensions: +... + file_storage: + directory: /tmp/otel-data + timeout: 10s + compaction: + directory: /tmp/otel-data + on_start: true + on_rebound: true + rebound_needed_threshold_mib: 5 + rebound_trigger_threshold_mib: 3 + +# ... truncated for clarity + +service: + extensions: [health_check, pprof, zpages, file_storage] +``` + +## なぜデヌタをディスクぞキュヌむングするのか? + +これにより Collector はネットワヌク䞭断さらには Collector の再起動にも耐えられるようになり、デヌタが䞊流のプロバむダヌに確実に送信されるこずを保蚌できたす。 + +## デヌタをディスクぞキュヌむングする際の考慮事項 + +ディスクのパフォヌマンス次第では、デヌタのスルヌプット性胜に圱響が出る可胜性がありたす。 + +### 参考資料 + +1. [https://community.splunk.com/t5/Community-Blog/Data-Persistence-in-the-OpenTelemetry-Collector/ba-p/624583](https://community.splunk.com/t5/Community-Blog/Data-Persistence-in-the-OpenTelemetry-Collector/ba-p/624583) +2. [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/storage/filestorage](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/storage/filestorage) + +{{% /expand %}} + +--- + +## 蚭定の確認 + +extension に぀いお䞀通り確認したので、蚭定の倉曎内容をチェックしたしょう。 + +--- + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}蚭定を確認する{{% /badge %}}" %}} +{{< tabs >}} +{{% tab title="config.yaml" %}} + +```yaml { lineNos="table" wrap="true" hl_lines="5" } +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + endpoint: 0.0.0.0:13133 + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + +exporters: + debug: + verbosity: detailed + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{< /tabs >}} +{{% /expand %}} + +--- + +extension の確認が完了したので、ワヌクショップのデヌタパむプラむンの郚分に進みたしょう。パむプラむンずは、Collector におけるデヌタの経路を定矩するもので、デヌタの受信から始たり、远加の凊理や倉換を経お、最終的に exporter を介しお Collector から出おいくたでを指したす。 + +OpenTelemetry Collector のデヌタパむプラむンは、**receiver**、**processor**、**exporter** で構成されおいたす。たずは receiver から芋おいきたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md new file mode 100644 index 0000000000..da7e0a1276 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md @@ -0,0 +1,37 @@ +--- +title: OpenTelemetry Collector Extensions +linkTitle: 2. Extensions +weight: 2 +--- + +OpenTelemetry Collector のむンストヌルが完了したので、次は OpenTelemetry Collector の拡匵機胜 (Extensions) に぀いお芋おいきたしょう。Extensions はオプションであり、䞻にテレメトリデヌタの凊理を䌎わないタスク向けに提䟛されたす。Extensions の䟋ずしおは、ヘルスモニタリング、サヌビスディスカバリ、デヌタ転送などがありたす。 + +{{< mermaid >}} +%%{ + init:{ + "theme": "base", + "themeVariables": { + "primaryColor": "#ffffff", + "clusterBkg": "#eff2fb", + "defaultLinkColor": "#333333" + } + } +}%% + +flowchart LR; + style E fill:#e20082,stroke:#333,stroke-width:4px,color:#fff + subgraph Collector + A[OTLP] --> M(Receivers) + B[JAEGER] --> M(Receivers) + C[Prometheus] --> M(Receivers) + end + subgraph Processors + M(Receivers) --> H(Filters, Attributes, etc) + E(Extensions) + end + subgraph Exporters + H(Filters, Attributes, etc) --> S(OTLP) + H(Filters, Attributes, etc) --> T(JAEGER) + H(Filters, Attributes, etc) --> U(Prometheus) + end +{{< /mermaid >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md new file mode 100644 index 0000000000..1d38fea4f9 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md @@ -0,0 +1,44 @@ +--- +title: OpenTelemetry Collector Receivers +linkTitle: 1. Host Metrics +weight: 1 +--- + +## Host Metrics Receiver + +[**The Host Metrics Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md) は、さたざたな゜ヌスからスクレむピングしたホストシステムに関するメトリクスを生成したす。これは Collector が゚ヌゞェントずしおデプロむされる際に䜿甚するこずを想定しおおり、本ワヌクショップでもその構成で進めたす。 + +`/etc/otel-contrib/config.yaml` ファむルを曎新しお **hostmetrics** receiver を蚭定したしょう。**receivers** セクションの䞋に、次の YAML を 2 スペヌスのむンデントに泚意しお挿入しおください。 + +``` bash +sudo vi /etc/otelcol-contrib/config.yaml +``` + +{{% tab title="Host Metrics Receiver Configuration" %}} + +```yaml {hl_lines="2-22"} +receivers: + hostmetrics: + collection_interval: 10s + scrapers: + # CPU utilization metrics + cpu: + # Disk I/O metrics + disk: + # File System utilization metrics + filesystem: + # Memory utilization metrics + memory: + # Network interface I/O metrics & TCP connection metrics + network: + # CPU load metrics + load: + # Paging/Swap space utilization and I/O metrics + paging: + # Process count metrics + processes: + # Per process CPU, Memory and Disk I/O metrics. Disabled by default. + # process: +``` + +{{% /tab %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md new file mode 100644 index 0000000000..c831bdb32f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md @@ -0,0 +1,35 @@ +--- +title: OpenTelemetry Collector Receivers +linkTitle: 2. Prometheus +weight: 2 +--- + +## Prometheus Receiver + +**prometheus** ずいう別の receiver にも気づくはずです。[**Prometheus**](https://prometheus.io/docs/introduction/overview/) は OpenTelemetry Collector で利甚されおいるオヌプン゜ヌスのツヌルキットです。この receiver は OpenTelemetry Collector 自身からメトリクスをスクレむピングするために䜿甚されたす。これらのメトリクスは Collector の健党性を監芖するために利甚できたす。 + +`prometheus` receiver が Collector 自身からメトリクスを収集しおいるこずを明確に瀺すよう倉曎しおみたしょう。receiver の名前を `prometheus` から `prometheus/internal` に倉曎するこずで、その receiver が䜕をしおいるのかがより分かりやすくなりたす。蚭定ファむルを以䞋のように曎新したす: + +{{% tab title="Prometheus Receiver Configuration" %}} + +```yaml {hl_lines="1"} +prometheus/internal: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] +``` + +{{% /tab %}} + +## ダッシュボヌドの䟋 - Prometheus メトリクス + +次のスクリヌンショットは、Prometheus internal receiver が OpenTelemetry Collector から収集するメトリクスのいく぀かをダッシュボヌドで瀺した䟋です。ここでは、受け入れられた、および送信された spans、metrics、log records を確認できたす。 + +{{% notice style="note" %}} +次のスクリヌンショットは、Splunk Observability Cloud のすぐに䜿える (OOTB) ダッシュボヌドであり、Splunk OpenTelemetry Collector のむンストヌル基盀を簡単に監芖できたす。 +{{% /notice %}} + +![otel-charts](../../images/otel-charts.png) diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md new file mode 100644 index 0000000000..e9766c9f53 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md @@ -0,0 +1,170 @@ +--- +title: OpenTelemetry Collector Receivers +linkTitle: 3. Other Receivers +weight: 3 +--- + +## その他のReceiver + +デフォルト蚭定には他にも **otlp**、**opencensus**、**jaeger**、**zipkin** ずいったReceiverが含たれおいるこずに気付くでしょう。これらは他の゜ヌスからテレメトリデヌタを受信するために䜿われたす。本ワヌクショップではこれらのReceiverは扱わないため、そのたたにしおおいお構いたせん。 + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Receiverを動的に䜜成する{{% /badge %}}" %}} + +dockerコンテナ、kubernetes pod、sshセッションなどの短呜なタスクを芳枬するために、[receiver creator](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/receivercreator) ず [observer extensions](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/observer) を䜿っお、これらのサヌビスが起動した際に新しいReceiverを䜜成するこずができたす。 + +## 必芁なもの + +receiver creatorず関連するobserver extensionsを䜿い始めるには、これらをCollectorのビルドマニフェストに含める必芁がありたす。 + +詳现は [installation](../1-installation/) を参照しおください。 + +## 考慮すべきこず + +短呜なタスクの䞭には、_username_ や _password_ などの远加蚭定が必芁になるものもありたす。 +これらの倀は [environment variables](https://opentelemetry.io/docs/collector/configuration/#configuration-environment-variables) で参照したり、`${file:./path/to/database/password}` のようなscheme expand構文を䜿うこずができたす。 +この方法を取る堎合は、所属組織のシヌクレット管理ポリシヌに埓っおください。 + +## The Ninja Zone + +このninja zoneで必芁なのは2぀だけです。 + +1. receiver createrずobserver extensionsをbuilderマニフェストに远加しおいるこずを確認する。 +2. 怜出された゚ンドポむントずマッチングするための蚭定を䜜成する。 + +テンプレヌト化された蚭定を䜜成するには、次のようにしたす。 + +```yaml +receiver_creator: + watch_observers: [host_observer] + receivers: + redis: + rule: type == "port" && port == 6379 + config: + password: ${env:HOST_REDIS_PASSWORD} +``` + +その他の䟋は、こちらの [receiver creator's examples](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/receivercreator#examples) を参照しおください。 + +{{% /expand %}} + +--- + +## 蚭定のチェックむン + +ここたででReceiverに぀いお説明したので、蚭定の倉曎内容を確認しおみたしょう。 + +--- + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}蚭定を確認する{{% /badge %}}" %}} +{{< tabs >}} +{{% tab title="config.yaml" %}} + +```yaml {lineNos="table" wrap="true" hl_lines="13-33 45"} +# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface. +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + endpoint: 0.0.0.0:13133 + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + hostmetrics: + collection_interval: 10s + scrapers: + # CPU utilization metrics + cpu: + # Disk I/O metrics + disk: + # File System utilization metrics + filesystem: + # Memory utilization metrics + memory: + # Network interface I/O metrics & TCP connection metrics + network: + # CPU load metrics + load: + # Paging/Swap space utilization and I/O metrics + paging: + # Process count metrics + processes: + # Per process CPU, Memory and Disk I/O metrics. Disabled by default. + # process: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus/internal: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + +exporters: + debug: + verbosity: detailed + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{< /tabs >}} +{{% /expand %}} + +--- + +ReceiverによっおOpenTelemetry Collectorにデヌタが入っおくる仕組みを確認したので、次はCollectorが受信したデヌタをどのように凊理するかを芋おいきたしょう。 + +{{% notice style="warning" %}} +`/etc/otelcol-contrib/config.yaml` はただ完成しおいないため、この時点ではCollectorを再起動 **しないでください**。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md new file mode 100644 index 0000000000..8d75ac99cc --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md @@ -0,0 +1,39 @@ +--- +title: OpenTelemetry Collector Receivers +linkTitle: 3. Receivers +weight: 3 +--- + +ワヌクショップの receiver パヌトぞようこそここは OpenTelemetry Collector におけるデヌタパむプラむンの起点ずなる郚分です。さっそく芋おいきたしょう。 + +receiver は push 型たたは pull 型のいずれかで動䜜し、Collector にデヌタを取り蟌む仕組みです。receiver は 1 ぀以䞊のデヌタ゜ヌスをサポヌトできたす。䞀般的に、receiver は指定されたフォヌマットでデヌタを受け取り、それを内郚フォヌマットに倉換したうえで、該圓するパむプラむンに定矩された processor や exporter ぞ受け枡したす。 + +{{< mermaid >}} +%%{ + init:{ + "theme":"base", + "themeVariables": { + "primaryColor": "#ffffff", + "clusterBkg": "#eff2fb", + "defaultLinkColor": "#333333" + } + } +}%% + +flowchart LR; + style M fill:#e20082,stroke:#333,stroke-width:4px,color:#fff + subgraph Collector + A[OTLP] --> M(Receivers) + B[JAEGER] --> M(Receivers) + C[Prometheus] --> M(Receivers) + end + subgraph Processors + M(Receivers) --> H(Filters, Attributes, etc) + E(Extensions) + end + subgraph Exporters + H(Filters, Attributes, etc) --> S(OTLP) + H(Filters, Attributes, etc) --> T(JAEGER) + H(Filters, Attributes, etc) --> U(Prometheus) + end +{{< /mermaid >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md new file mode 100644 index 0000000000..66f5f0f358 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md @@ -0,0 +1,15 @@ +--- +title: OpenTelemetry Collector Processors +linkTitle: 4.1 Batch +weight: 1 +--- + +## Batch Processor + +デフォルトでは、**batch** プロセッサヌのみが有効になっおいたす。このプロセッサヌは、デヌタを゚クスポヌトする前にバッチ凊理するために䜿甚されたす。これにより、゚クスポヌタヌぞのネットワヌク呌び出し回数を削枛できたす。本ワヌクショップでは、Collector にハヌドコヌドされおいる以䞋のデフォルト倀を継承したす。 + +- `send_batch_size` (default = 8192): タむムアりトに関わらずバッチが送信される、スパン、メトリックデヌタポむント、たたはログレコヌドの数です。send_batch_size はトリガヌずしお機胜し、バッチのサむズには圱響したせん。パむプラむンの次のコンポヌネントに送信するバッチサむズの䞊限を匷制したい堎合は、send_batch_max_size を参照しおください。 +- `timeout` (default = 200ms): サむズに関わらずバッチが送信されるたでの時間です。れロに蚭定するず、send_batch_size は無芖され、デヌタは send_batch_max_size のみを条件ずしお盎ちに送信されたす。 +- `send_batch_max_size` (default = 0): バッチサむズの䞊限です。0 はバッチサむズに䞊限がないこずを意味したす。このプロパティは、より倧きなバッチが小さな単䜍に分割されるこずを保蚌したす。send_batch_size 以䞊の倀である必芁がありたす。 + +Batch プロセッサヌの詳现に぀いおは、[**Batch Processor documentation**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md) を参照しおください。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md new file mode 100644 index 0000000000..5bdbf9bd18 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md @@ -0,0 +1,53 @@ +--- +title: OpenTelemetry Collector Processors +linkTitle: 4.2 Resource Detection +weight: 2 +--- + +## Resource Detection Processor + +**resourcedetection** プロセッサヌは、ホストからリ゜ヌス情報を怜出し、その情報をテレメトリヌデヌタのリ゜ヌス倀ずしお远加たたは䞊曞きするために䜿甚できたす。 + +デフォルトでは、可胜な堎合は FQDN がホスト名ずしお蚭定され、それ以倖の堎合は OS が提䟛するホスト名がフォヌルバックずしお䜿甚されたす。この動䜜は `hostname_sources` 蚭定オプションを䜿甚しお倉曎できたす。FQDN の取埗を避けお OS が提䟛するホスト名を䜿甚するために、`hostname_sources` を `os` に蚭定したす。 + +{{% tab title="System Resource Detection Processor Configuration" %}} + +``` yaml {hl_lines="3-7"} +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] +``` + +{{% /tab %}} + +ワヌクショップのむンスタンスが AWS/EC2 むンスタンス䞊で実行されおいる堎合、EC2 メタデヌタ API から以䞋のタグを取埗できたすこれは他のプラットフォヌムでは利甚できたせん。 + +- `cloud.provider ("aws")` +- `cloud.platform ("aws_ec2")` +- `cloud.account.id` +- `cloud.region` +- `cloud.availability_zone` +- `host.id` +- `host.image.id` +- `host.name` +- `host.type` + +これらのタグをメトリクスに远加するために、もう1぀のプロセッサヌを䜜成したす。 + +{{% tab title="EC2 Resource Detection Processor Configuration" %}} + +``` yaml {hl_lines="7-8"} +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] + resourcedetection/ec2: + detectors: [ec2] +``` + +{{% /tab %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md new file mode 100644 index 0000000000..802240b19f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md @@ -0,0 +1,200 @@ +--- +title: OpenTelemetry Collector Processors +linkTitle: 4.3 Attributes +weight: 3 +--- + +## Attributes Processor + +attributes processor は、span、log、metric の属性を倉曎したす。このプロセッサヌは、入力デヌタをフィルタリング・マッチングしお、指定したアクションの察象に含めるか陀倖するかを刀定する機胜もサポヌトしおいたす。 + +蚭定で指定された順番で実行される䞀連のアクションを受け取りたす。サポヌトされおいるアクションは次のずおりです。 + +- `insert`: キヌがただ存圚しない堎合に、入力デヌタぞ新しい属性を挿入したす。 +- `update`: キヌが存圚する堎合に、入力デヌタの属性を曎新したす。 +- `upsert`: insert たたは update を実行したす。キヌが存圚しない堎合は新しい属性を挿入し、キヌが存圚する堎合は属性を曎新したす。 +- `delete`: 入力デヌタから属性を削陀したす。 +- `hash`: 既存の属性倀をハッシュ化SHA1したす。 +- `extract`: 正芏衚珟ルヌルを䜿甚しお、入力キヌからルヌルに指定されたタヌゲットキヌぞ倀を抜出したす。タヌゲットキヌが既に存圚する堎合は䞊曞きされたす。 + +これから、すべおのホストメトリクスに `participant.name` ずいう新しい属性を `insert` する attributes processor を䜜成したす。倀にはご自身の名前䟋: `marge_simpson`を蚭定したす。 + +{{% notice style="warning" %}} + +`INSERT_YOUR_NAME_HERE` は必ずご自身の名前に眮き換えおください。たた、名前にスペヌスを **䜿甚しない** ようにしおください。 + +{{% /notice %}} + +ワヌクショップの埌半では、この属性を䜿甚しお Splunk Observability Cloud のメトリクスをフィルタリングしたす。 + +{{% tab title="Attributes Processor Configuration" %}} + +``` yaml {hl_lines="9-13"} +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] + resourcedetection/ec2: + detectors: [ec2] + attributes/conf: + actions: + - key: participant.name + action: insert + value: "INSERT_YOUR_NAME_HERE" +``` + +{{%/ tab %}} + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Using connectors to gain internal insights{{% /badge %}}" %}} + +Collector に最近远加されたものの䞀぀に [**connector**](https://opentelemetry.io/docs/collector/configuration/#connectors) ずいう抂念があり、あるパむプラむンの出力を別のパむプラむンの入力に぀なぐこずができたす。 + +これがどのように圹立぀かの䟋ずしお、゚クスポヌトされたデヌタポむントの量、゚ラヌステヌタスを含むログの数、あるデプロむ環境から送信されたデヌタの量に基づいおメトリクスを発行するサヌビスがありたす。count connector はこれを暙準で察応しおくれたす。 + +## なぜプロセッサヌではなくコネクタヌなのか? + +プロセッサヌは、凊理したデヌタをそのたた枡さなければならないため、远加で生成できるデヌタが限られおおり、远加情報を公開するのが困難です。コネクタヌは受け取ったデヌタをそのたた発行する必芁がないため、求めおいるむンサむトを生み出す機䌚を提䟛しおくれたす。 + +䟋えば、デプロむ環境属性を持たないログ、メトリクス、トレヌスの数をカりントするコネクタヌを䜜成できたす。 + +非垞にシンプルな䟋ずしお、デプロむ環境ごずにデヌタ䜿甚量を分解しお出力できたす。 + +## コネクタヌを䜿う際の考慮事項 + +コネクタヌは、あるパむプラむンから゚クスポヌトされ、別のパむプラむンで受信されるデヌタのみを受け付けたす。これを掻甚するためには、Collector の蚭定をどのように構成するかを考慮する必芁がありたす。 + +## References + +1. [**https://opentelemetry.io/docs/collector/configuration/#connectors**](https://opentelemetry.io/docs/collector/configuration/#connectors) +2. [**https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector) + +{{% /expand %}} + +--- + +## Configuration Check-in + +プロセッサヌに぀いおは以䞊です。蚭定の倉曎内容を確認しおみたしょう。 + +--- + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your configuration{{% /badge %}}" %}} +{{< tabs >}} +{{% tab title="config.yaml" %}} + +```yaml {lineNos="table" wrap="true" hl_lines="69-79"} +# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface. +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + endpoint: 0.0.0.0:13133 + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + hostmetrics: + collection_interval: 10s + scrapers: + # CPU utilization metrics + cpu: + # Disk I/O metrics + disk: + # File System utilization metrics + filesystem: + # Memory utilization metrics + memory: + # Network interface I/O metrics & TCP connection metrics + network: + # CPU load metrics + load: + # Paging/Swap space utilization and I/O metrics + paging: + # Process count metrics + processes: + # Per process CPU, Memory and Disk I/O metrics. Disabled by default. + # process: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus/internal: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] + resourcedetection/ec2: + detectors: [ec2] + attributes/conf: + actions: + - key: participant.name + action: insert + value: "INSERT_YOUR_NAME_HERE" + +exporters: + debug: + verbosity: detailed + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{< /tabs >}} +{{% /expand %}} + +--- diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md new file mode 100644 index 0000000000..54ee4e4052 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md @@ -0,0 +1,37 @@ +--- +title: OpenTelemetry Collector Processors +linkTitle: 4. Processors +weight: 4 +--- + +[**Processors**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/README.md) は、デヌタが受信されおから゚クスポヌトされるたでの間に実行されたす。Processors はオプションですが、掚奚されるものもありたす。OpenTelemetry contrib Collector には [**倚数の Processors**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor) が含たれおいたす。 + +{{< mermaid >}} +%%{ + init:{ + "theme":"base", + "themeVariables": { + "primaryColor": "#ffffff", + "clusterBkg": "#eff2fb", + "defaultLinkColor": "#333333" + } + } +}%% + +flowchart LR; + style Processors fill:#e20082,stroke:#333,stroke-width:4px,color:#fff + subgraph Collector + A[OTLP] --> M(Receivers) + B[JAEGER] --> M(Receivers) + C[Prometheus] --> M(Receivers) + end + subgraph Processors + M(Receivers) --> H(Filters, Attributes, etc) + E(Extensions) + end + subgraph Exporters + H(Filters, Attributes, etc) --> S(OTLP) + H(Filters, Attributes, etc) --> T(JAEGER) + H(Filters, Attributes, etc) --> U(Prometheus) + end +{{< /mermaid >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md new file mode 100644 index 0000000000..702520c338 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md @@ -0,0 +1,199 @@ +--- +title: OpenTelemetry Collector Exporters +linkTitle: 5.1 OTLP HTTP +weight: 1 +--- + +## OTLP HTTP Exporter + +メトリクスを HTTP 経由で Splunk Observability Cloud に送信するには、**otlphttp** exporter を蚭定する必芁がありたす。 + +`/etc/otelcol-contrib/config.yaml` ファむルを線集しお、**otlphttp** exporter を蚭定しおみたしょう。**exporters** セクションの䞋に、以䞋の YAML を 2 スペヌスのむンデントに泚意しお挿入したす。 + +たた、ディスクが満杯になるのを防ぐために、logging exporter のログレベルも倉曎したす。デフォルトの `detailed` は非垞に冗長です。 + +```yaml {hl_lines="3-4"} +exporters: + debug: + verbosity: normal + otlphttp/splunk: +``` + +次に、`metrics_endpoint` を定矩しおタヌゲット URL を蚭定する必芁がありたす。 + +{{% notice style="note" %}} +Splunk 䞻催のワヌクショップに参加されおいる方は、䜿甚しおいるむンスタンスにすでに Realm 環境倉数が蚭定されおいたす。蚭定ファむルでその環境倉数を参照したす。それ以倖の堎合は、新しい環境倉数を䜜成しお Realm を蚭定する必芁がありたす。䟋 + +``` bash +export REALM="us1" +``` + +{{% /notice %}} + +䜿甚する URL は `https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp` です。Splunk はデヌタレゞデンシヌのために、䞖界䞭の䞻芁な地理的拠点に Realm を持っおいたす。 + +**otlphttp** exporter は、`traces_endpoint` ず `logs_endpoint` のタヌゲット URL をそれぞれ定矩するこずで、トレヌスずログを送信するように蚭定するこずもできたす。これらの蚭定は本ワヌクショップの範囲倖です。 + +```yaml {hl_lines="5"} +exporters: + debug: + verbosity: normal + otlphttp/splunk: + metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp +``` + +デフォルトでは、すべおの゚ンドポむントで `gzip` 圧瞮が有効になっおいたす。これは exporter の蚭定で `compression: none` を指定するこずで無効にできたす。本ワヌクショップでは、これがデヌタ送信の最も効率的な方法であるため、圧瞮を有効のたたにしおデフォルトを採甚したす。 + +メトリクスを Splunk Observability Cloud に送信するには、Access Token を䜿甚する必芁がありたす。これは Splunk Observability Cloud UI で新しいトヌクンを䜜成するこずで行えたす。トヌクンの䜜成方法の詳现に぀いおは、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照しおください。トヌクンは **INGEST** タむプである必芁がありたす。 + +{{% notice style="note" %}} +Splunk 䞻催のワヌクショップに参加されおいる方は、䜿甚しおいるむンスタンスにすでに Access Token が環境倉数ずしお蚭定されおいたす。蚭定ファむルでその環境倉数を参照したす。それ以倖の堎合は、新しいトヌクンを䜜成しお環境倉数ずしお蚭定する必芁がありたす。䟋 + +``` bash +export ACCESS_TOKEN= +``` + +{{% /notice %}} + +トヌクンは、蚭定ファむル内で `headers:` セクションの䞋に `X-SF-TOKEN: ${env:ACCESS_TOKEN}` を挿入するこずで定矩したす。 + +```yaml {hl_lines="6-8"} +exporters: + debug: + verbosity: normal + otlphttp/splunk: + metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp + headers: + X-SF-TOKEN: ${env:ACCESS_TOKEN} +``` + +## Configuration Check-in + +exporter に぀いお説明したので、蚭定倉曎を確認したしょう。 + +--- + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your configuration{{% /badge %}}" %}} +{{< tabs >}} +{{% tab title="config.yaml" %}} + +```yaml {lineNos="table" wrap="true" hl_lines="83-87"} +# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface. +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + endpoint: 0.0.0.0:13133 + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + hostmetrics: + collection_interval: 10s + scrapers: + # CPU utilization metrics + cpu: + # Disk I/O metrics + disk: + # File System utilization metrics + filesystem: + # Memory utilization metrics + memory: + # Network interface I/O metrics & TCP connection metrics + network: + # CPU load metrics + load: + # Paging/Swap space utilization and I/O metrics + paging: + # Process count metrics + processes: + # Per process CPU, Memory and Disk I/O metrics. Disabled by default. + # process: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus/internal: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] + resourcedetection/ec2: + detectors: [ec2] + attributes/conf: + actions: + - key: participant.name + action: insert + value: "INSERT_YOUR_NAME_HERE" + +exporters: + debug: + verbosity: normal + otlphttp/splunk: + metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp + headers: + X-SF-Token: ${env:ACCESS_TOKEN} + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{< /tabs >}} +{{% /expand %}} + +--- + +もちろん、`metrics_endpoint` を **OTLP** プロトコルをサポヌトする他の゜リュヌションを指すように簡単に蚭定するこずもできたす。 + +次に、`config.yaml` の service セクションで、蚭定したばかりの receiver、processor、exporter を有効化する必芁がありたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md new file mode 100644 index 0000000000..9ed5a81d75 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md @@ -0,0 +1,39 @@ +--- +title: OpenTelemetry Collector Exporters +linkTitle: 5. Exporters +weight: 5 +--- + +゚クスポヌタヌは、push 型たたは pull 型のいずれかで動䜜し、デヌタを 1 ぀以䞊のバック゚ンドや宛先ぞ送信する仕組みです。゚クスポヌタヌは 1 ぀たたは耇数のデヌタ゜ヌスに察応したす。 + +このワヌクショップでは、[**otlphttp**](https://opentelemetry.io/docs/specs/otel/protocol/exporter/) ゚クスポヌタヌを䜿甚したす。OpenTelemetry Protocol (OTLP) は、テレメトリデヌタを送信するためのベンダヌ䞭立で暙準化されたプロトコルです。OTLP ゚クスポヌタヌは、OTLP プロトコルを実装したサヌバヌぞデヌタを送信したす。OTLP ゚クスポヌタヌは [**gRPC**](https://grpc.io/) ず [**HTTP**](https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview)/[**JSON**](https://www.json.org/json-en.html) の䞡方のプロトコルをサポヌトしおいたす。 + +{{< mermaid >}} +%%{ + init:{ + "theme":"base", + "themeVariables": { + "primaryColor": "#ffffff", + "clusterBkg": "#eff2fb", + "defaultLinkColor": "#333333" + } + } +}%% + +flowchart LR; + style Exporters fill:#e20082,stroke:#333,stroke-width:4px,color:#fff + subgraph Collector + A[OTLP] --> M(Receivers) + B[JAEGER] --> M(Receivers) + C[Prometheus] --> M(Receivers) + end + subgraph Processors + M(Receivers) --> H(Filters, Attributes, etc) + E(Extensions) + end + subgraph Exporters + H(Filters, Attributes, etc) --> S(OTLP) + H(Filters, Attributes, etc) --> T(JAEGER) + H(Filters, Attributes, etc) --> U(Prometheus) + end +{{< /mermaid >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md new file mode 100644 index 0000000000..850631ad1f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md @@ -0,0 +1,27 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6.1 Host Metrics +weight: 1 +--- + +## Hostmetrics Receiver + +ワヌクショップの Receivers セクションを思い出しおください。[**Host Metrics Receiver**](../3-receivers/#host-metrics-receiver) は、さたざたな゜ヌスからスクレむピングされる、ホストシステムに関するメトリクスを生成するために定矩したした。このレシヌバヌを有効化するには、metrics パむプラむンに `hostmetrics` レシヌバヌを含める必芁がありたす。 + +`metrics` パむプラむンの `receivers` セクションに `hostmetrics` を远加したす。 + +```yaml {hl_lines="11"} +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus] + processors: [batch] + exporters: [debug] +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md new file mode 100644 index 0000000000..6e3989fd9b --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md @@ -0,0 +1,27 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6.2 Prometheus +weight: 2 +--- + +## Prometheus Internal Receiver + +ワヌクショップの前半で、`prometheus` レシヌバヌが Collector 内郚のメトリクスを収集しおいるこずを反映させるため、`prometheus/internal` ずいう名前に倉曎したした。 + +ここで、メトリクスパむプラむンで `prometheus/internal` レシヌバヌを有効化する必芁がありたす。`receivers` セクションを曎新し、`metrics` パむプラむンに `prometheus/internal` を远加しおください: + +```yaml {hl_lines="11"} +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus/internal] + processors: [batch] + exporters: [debug] +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md new file mode 100644 index 0000000000..15c671d5a5 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md @@ -0,0 +1,27 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6.3 Resource Detection +weight: 3 +--- + +## Resource Detection Processor + +Collector がむンスタンスのホスト名や AWS/EC2 メタデヌタを取埗できるよう、`resourcedetection/system` ず `resourcedetection/ec2` プロセッサヌも远加したした。これら 2 ぀のプロセッサヌを metrics パむプラむンで有効化する必芁がありたす。 + +`processors` セクションを曎新しお、`metrics` パむプラむンに `resourcedetection/system` ず `resourcedetection/ec2` を含めたす。 + +```yaml {hl_lines="12"} +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus/internal] + processors: [batch, resourcedetection/system, resourcedetection/ec2] + exporters: [debug] +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md new file mode 100644 index 0000000000..af2ef0765a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md @@ -0,0 +1,27 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6.4 Attributes +weight: 4 +--- + +## Attributes Processor + +このワヌクショップの Processors セクションでも、`attributes/conf` プロセッサヌを远加しお、Collector がすべおのメトリクスに `participant.name` ずいう新しい属性を挿入するようにしたした。次に、これを metrics パむプラむンで有効化する必芁がありたす。 + +`processors` セクションを曎新しお、`metrics` パむプラむンに `attributes/conf` を含めたす。 + +```yaml {hl_lines="12"} +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus/internal] + processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] + exporters: [debug] +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md new file mode 100644 index 0000000000..25fc40bb3c --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md @@ -0,0 +1,243 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6.5 OTLP HTTP +weight: 5 +--- + +## OTLP HTTP Exporter + +ワヌクショップの Exporters セクションでは、Splunk Observability Cloud にメトリクスを送信するための `otlphttp` exporter を構成したした。次は、これを metrics パむプラむンで有効化する必芁がありたす。 + +`exporters` セクションを曎新し、`metrics` パむプラむンに `otlphttp/splunk` を含めたす。 + +```yaml {hl_lines="13"} +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus/internal] + processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] + exporters: [debug, otlphttp/splunk] +``` + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Collector の内郚芳枬{{% /badge %}}" %}} + +Collector は自身の振る舞いに関する内郚シグナルを取埗しおおり、これには皌働䞭のコンポヌネントから埗られる远加のシグナルも含たれたす。 +これは、デヌタの流れに関する刀断を行うコンポヌネントが、その情報をメトリクスやトレヌスずしお衚面化する手段を必芁ずするためです。 + +## なぜ Collector を監芖するのか + +これは「監芖者を監芖するのは誰か」ずいう、いわば鶏ず卵の問題ですが、こうした情報を衚面化できるこずは重芁です。Collector の歎史的に興味深いもう 1 ぀の点ずしお、Collector は Go の metrics SDK が安定版ずみなされる前から存圚しおいたため、珟時点ではこの機胜を提䟛する目的で Prometheus ゚ンドポむントを公開しおいる、ずいう事情がありたす。 + +## 考慮事項 + +組織内で皌働䞭の各 Collector の内郚䜿甚状況を監芖するず、新しい Metric Time Series (MTS) が倧量に発生する可胜性がありたす。Splunk ディストリビュヌションではこれらのメトリクスを粟遞しおおり、想定される増加分の予枬を支揎できたす。 + +## The Ninja Zone + +Collector の内郚可芳枬性を公開するには、いく぀かの远加蚭定を調敎できたす。 + +{{< tabs >}} +{{% tab title="telemetry schema" %}} + +```yaml +service: + telemetry: + logs: + level: + development: + encoding: + disable_caller: + disable_stacktrace: + output_paths: [, paths...] + error_output_paths: [, paths...] + initial_fields: + key: value + metrics: + level: + # Address binds the promethues endpoint to scrape + address: +``` + +{{% /tab %}} +{{% tab title="example-config.yml" %}} + +```yaml +service: + telemetry: + logs: + level: info + encoding: json + disable_stacktrace: true + initial_fields: + instance.name: ${env:INSTANCE} + metrics: + address: localhost:8888 +``` + +{{% /tab %}} +{{< /tabs >}} + +## 参考情報 + +1. [https://opentelemetry.io/docs/collector/configuration/#service](https://opentelemetry.io/docs/collector/configuration/#service) + +{{% /expand %}} + +--- + +## 最終的な構成 + +--- + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}最終的な構成を確認する{{% /badge %}}" %}} +{{< tabs >}} +{{% tab title="config.yaml" %}} + +``` yaml {lineNos="table" wrap="true"} +# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface. +# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks + +extensions: + health_check: + endpoint: 0.0.0.0:13133 + pprof: + endpoint: 0.0.0.0:1777 + zpages: + endpoint: 0.0.0.0:55679 + +receivers: + hostmetrics: + collection_interval: 10s + scrapers: + # CPU utilization metrics + cpu: + # Disk I/O metrics + disk: + # File System utilization metrics + filesystem: + # Memory utilization metrics + memory: + # Network interface I/O metrics & TCP connection metrics + network: + # CPU load metrics + load: + # Paging/Swap space utilization and I/O metrics + paging: + # Process count metrics + processes: + # Per process CPU, Memory and Disk I/O metrics. Disabled by default. + # process: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + + opencensus: + endpoint: 0.0.0.0:55678 + + # Collect own metrics + prometheus/internal: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] + + jaeger: + protocols: + grpc: + endpoint: 0.0.0.0:14250 + thrift_binary: + endpoint: 0.0.0.0:6832 + thrift_compact: + endpoint: 0.0.0.0:6831 + thrift_http: + endpoint: 0.0.0.0:14268 + + zipkin: + endpoint: 0.0.0.0:9411 + +processors: + batch: + resourcedetection/system: + detectors: [system] + system: + hostname_sources: [os] + resourcedetection/ec2: + detectors: [ec2] + attributes/conf: + actions: + - key: participant.name + action: insert + value: "INSERT_YOUR_NAME_HERE" + +exporters: + debug: + verbosity: normal + otlphttp/splunk: + metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp + headers: + X-SF-Token: ${env:ACCESS_TOKEN} + +service: + + pipelines: + + traces: + receivers: [otlp, opencensus, jaeger, zipkin] + processors: [batch] + exporters: [debug] + + metrics: + receivers: [hostmetrics, otlp, opencensus, prometheus/internal] + processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] + exporters: [debug, otlphttp/splunk] + + logs: + receivers: [otlp] + processors: [batch] + exporters: [debug] + + extensions: [health_check, pprof, zpages] +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /expand %}} + +--- + +{{% notice style="tip" %}} +Collector を再起動する前に、構成ファむルを怜蚌するこずを掚奚したす。`config.yaml` ファむルの内容を **[otelbin.io](https://www.otelbin.io/)** に貌り付けるこずで怜蚌できたす。 + +{{% expand title="{{% badge color=green title=**Screenshot** %}}OTelBin{{% /badge %}}" %}} +![otelbin-validator](../../images/otelbin.png) +{{% /expand %}} + +{{% /notice %}} + +動䜜する構成ができたので、Collector を起動し、[zPages](../2-extensions/#zpages) が䜕を報告しおいるか確認したしょう。 + +{{% tab title="Command" %}} + +``` bash +otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml +``` + +{{% /tab %}} + +ブラりザで zPages を開きたす: [**http://localhost:55679/debug/pipelinez**](http://localhost:55679/debug/pipelinez) `localhost` は自身の環境に合わせお倉曎しおください。 +![pipelinez-full-config](../../images/pipelinez-full-config.png) diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md new file mode 100644 index 0000000000..e20b0b8c10 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md @@ -0,0 +1,26 @@ +--- +title: OpenTelemetry Collector Service +linkTitle: 6. Service +weight: 6 +--- + +**Service** セクションは、receivers、processors、exporters、extensions の各セクションに定矩された蚭定をもずに、Collector で有効化するコンポヌネントを指定するために䜿甚したす。 + +{{% notice style="info" %}} +コンポヌネントが蚭定されおいおも、**Service** セクション内で定矩されおいなければ、そのコンポヌネントは有効化**されたせん**。 +{{% /notice %}} + +service セクションは、次の3぀のサブセクションで構成されおいたす。 + +- extensions +- pipelines +- telemetry + +デフォルトの蚭定では、extension セクションに `health_check`、`pprof`、`zpages` を有効化する蚭定が蚘述されおおり、これらは先ほど Extensions モゞュヌルで蚭定した内容です。 + +``` yaml +service: + extensions: [health_check, pprof, zpages] +``` + +それでは、Metric Pipeline を蚭定しおいきたしょう diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md new file mode 100644 index 0000000000..0ee8f7345d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md @@ -0,0 +1,38 @@ +--- +title: Data Visualisations +linkTitle: 7. Visualisation +weight: 7 +--- + +## Splunk Observability Cloud + +OpenTelemetry Collector が Splunk Observability Cloud にメトリクスを送信するように蚭定できたので、Splunk Observability Cloud でデヌタを確認しおみたしょう。Splunk Observability Cloud ぞの招埅を受け取っおいない堎合は、講垫がログむン認蚌情報を提䟛したす。 + +その前に、もう少し面癜くするために、むンスタンスに察しおストレステストを実行したす。これによりダッシュボヌドが掻性化されたす。 + +``` bash +sudo apt install stress +while true; do stress -c 2 -t 40; stress -d 5 -t 40; stress -m 20 -t 40; done +``` + +Splunk Observability Cloud にログむンしたら、巊偎のナビゲヌションを䜿甚しお、メむンメニュヌから **Dashboards** に移動したす。これにより Teams ビュヌが衚瀺されたす。このビュヌの䞊郚で **All Dashboards** をクリックしたす。 + +![menu-dashboards](../images/menu-dashboards.png) + +怜玢ボックスで **OTel Contrib** を怜玢したす。 + +![search-dashboards](../images/search-dashboards.png) + +{{% notice style="info" %}} +ダッシュボヌドが存圚しない堎合、講垫が玠早く远加できたす。Splunk がホストするバヌゞョンのワヌクショップに参加しおいない堎合、むンポヌトする Dashboard Group はこのペヌゞの䞋郚にありたす。 +{{% /notice %}} + +**OTel Contrib Dashboard** ダッシュボヌドをクリックしお開き、次にダッシュボヌド䞊郚の **Participant Name** ボックスをクリックし、`config.yaml` で `participant.name` に蚭定した名前をドロップダりンリストから遞択するか、怜玢のために名前を入力し始めたす。 + +![select-conf-attendee-name](../images/select-participant-name.png) + +これで、OpenTelemetry Collector を蚭定したホストのホストメトリクスを確認できるようになりたす。 + +![participant-dashboard](../images/participant-dashboard.png) + +{{% resources sort="asc" style="info" title="Download Dashboard Group JSON for importing" /%}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md new file mode 100644 index 0000000000..fda54d5236 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md @@ -0,0 +1,34 @@ +--- +title: OpenTelemetry Collector Development +linkTitle: 8.1 Project Setup +weight: 9 +--- + +## Project Setup {{% badge style=primary icon=user-ninja %}}**Ninja**{{% /badge %}} + +{{% notice style="note" %}} + +このセクションを完了するたでにかかる時間は、経隓により異なりたす。 + +詰たったずきやむンストラクタヌず䞀緒に進めたい堎合は、完成版の゜リュヌションを[**こちら**](https://github.com/splunk/collector-workshop-example)で確認できたす。 + +{{% /notice %}} + +新しい _Jenkins CI_ receiver の開発を始めるために、たずは Golang プロゞェクトをセットアップする必芁がありたす。 +新しい Golang プロゞェクトを䜜成する手順は以䞋のずおりです。 + +1. `${HOME}/go/src/jenkinscireceiver` ずいう名前の新しいディレクトリを䜜成し、そこに移動したす + 1. 実際のディレクトリ名や堎所に厳密な決たりはなく、ご自身の開発ディレクトリを自由に遞んで䜜成しお構いたせん。 +1. `go mod init splunk.conf/workshop/example/jenkinscireceiver` を実行しお golang モゞュヌルを初期化したす + 1. これにより `go.mod` ずいうファむルが䜜成され、盎接および間接の䟝存関係を远跡するために䜿甚されたす + 1. 最終的には `go.sum` も䜜成され、これはむンポヌトされる䟝存関係のチェックサム倀を保持したす。 + +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your go.mod{{% /badge %}}" %}} + +``` text +module splunk.conf/workshop/example/jenkinscireceiver + +go 1.20 +``` + +{{% /expand %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md new file mode 100644 index 0000000000..a494959de3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md @@ -0,0 +1,93 @@ +--- +title: OpenTelemetry Collector Development +linkTitle: 8.2 Configuration +weight: 10 +--- + +## 蚭定の構築 + +コンポヌネントの蚭定郚分は、ナヌザヌがコンポヌネントに察しお入力を䞎えるための手段です。 +そのため、蚭定で䜿甚される倀は次のような特性を備えおいる必芁がありたす。 + +1. そのフィヌルドが䜕を制埡するのかをナヌザヌが盎感的に理解できるこず +1. 必須項目ず任意項目が明瀺されおいるこず +1. 共通の名称やフィヌルドを再利甚しおいるこず +1. オプションをシンプルに保぀こず + +{{% tabs %}} +{{% tab title="bad config" %}} + +```yaml +--- +jenkins_server_addr: hostname +jenkins_server_api_port: 8089 +interval: 10m +filter_builds_by: + - name: my-awesome-build + status: amber +track: + values: + example.metric.1: yes + example.metric.2: yes + example.metric.3: no + example.metric.4: no +``` + +{{% /tab %}} +{{% tab title="good config" %}} + +``` yaml +--- +# Required Values +endpoint: http://my-jenkins-server:8089 +auth: + authenticator: basicauth/jenkins +# Optional Values +collection_interval: 10m +metrics: + example.metric.1: + enabled: true + example.metric.2: + enabled: true + example.metric.3: + enabled: true + example.metric.4: + enabled: true +``` + +{{% /tab %}} +{{% /tabs %}} + +bad configuration の䟋は、蚭定に関する掚奚事項ずは逆のこずを行うずコンポヌネントの䜿い勝手にどのような圱響を䞎えるかを瀺しおいたす。フィヌルドの倀がどうあるべきかが明確でなく、既存のプロセッサに任せられる機胜たで含めおしたっおおり、フィヌルドの呜名も collector 内の他のコンポヌネントず䞀貫しおいたせん。 + +good configuration の䟋は、必須の倀をシンプルに保ち、他のコンポヌネントから呜名芏則を再利甚し、コンポヌネントが Jenkins ず collector の連携のみに集䞭するようにしおいたす。 + +コヌドタブは、自分たちで远加する必芁のある郚分ず、collector 内の共有ラむブラリによっおすでに提䟛されおいる郚分の量を瀺しおいたす。これらに぀いおは、ビゞネスロゞックに進んだ際にさらに詳しく説明したす。蚭定は最初は小さく始めるべきであり、ビゞネスロゞックで必芁ずなる远加機胜を含めおいく過皋で倉化しおいきたす。 + +## コヌドを曞く + +蚭定に必芁なコヌドを実装するために、`config.go` ずいう名前の新しいファむルを以䞋の内容で䜜成したす。 + +``` go +package jenkinscireceiver + +import ( + "go.opentelemetry.io/collector/config/confighttp" + "go.opentelemetry.io/collector/receiver/scraperhelper" + + "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata" +) + +type Config struct { + // HTTPClientSettings contains all the values + // that are commonly shared across all HTTP interactions + // performed by the collector. + confighttp.HTTPClientSettings `mapstructure:",squash"` + // ScraperControllerSettings will allow us to schedule + // how often to check for updates to builds. + scraperhelper.ScraperControllerSettings `mapstructure:",squash"` + // MetricsBuilderConfig contains all the metrics + // that can be configured. + metadata.MetricsBuilderConfig `mapstructure:",squash"` +} +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md new file mode 100644 index 0000000000..f6d9ad2179 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md @@ -0,0 +1,64 @@ +--- +title: OpenTelemetry Collector Development +linkTitle: 8.3 コンポヌネントの埩習 +weight: 11 +--- + +## コンポヌネントの埩習 + +Jenkins からメトリクスを取埗するために必芁なコンポヌネントの皮類に぀いお、これたでの内容を振り返りたす。 + +{{% tabs %}} +{{% tab title="Extension" %}} +extension が解決するビゞネスナヌスケヌスは以䞋のずおりです。 + +1. ランタむム蚭定が必芁な共有機胜を提䟛する +1. Collector のランタむムを芳枬する間接的な手助けをする + +詳现は [**Extensions Overview**](../2-extensions) を参照しおください。 +{{% /tab %}} +{{% tab title="Receiver" %}} +receiver が解決するビゞネスナヌスケヌスは以䞋のずおりです。 + +- リモヌト゜ヌスからデヌタを取埗する +- リモヌト゜ヌスからデヌタを受信する + +これは䞀般的に _pull_ 型ず _push_ 型のデヌタ収集ず呌ばれ、詳现は [Receiver Overview](../3-receivers) で確認できたす。 +{{% /tab %}} +{{% tab title="Processor" %}} +processor が解決するビゞネスナヌスケヌスは以䞋のずおりです。 + +- デヌタ、フィヌルド、たたは倀の远加や削陀 +- デヌタを芳枬し、刀断を行う +- バッファリング、キュヌむング、䞊び替え + +ここで芚えおおくべき点は、processor を流れるデヌタタむプは、䞋流のコンポヌネントに同じデヌタタむプを転送する必芁があるずいうこずです。詳现は [Processor Overview](../4-processors) を読んでください。 + +{{% /tab %}} +{{% tab title="Exporter" %}} +exporter が解決するビゞネスナヌスケヌスは以䞋のずおりです。 + +- ツヌル、サヌビス、たたはストレヌゞにデヌタを送信する + +OpenTelemetry Collector は「バック゚ンド」やオヌルむンワンの可芳枬性スむヌトになるこずを目指しおいたせん。むしろ、OpenTelemetry が圓初から掲げおきた原則、぀たり「すべおの人にベンダヌニュヌトラルな可芳枬性を」ずいう理念を守るこずを重芖しおいたす。 +詳现を改めお確認するには、[**Exporter Overview**](../5-exporters) を読んでください。 + +{{% /tab %}} +{{% tab title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Connectors{{% /badge %}}" %}} + +これは、Collector に比范的最近远加されたコンポヌネントタむプであるため、本ワヌクショップでは觊れおいなかったものです。connector を理解する最良の方法は、異なるテレメトリヌタむプやパむプラむンをたたいで䜿甚できる processor のようなものだず考えるこずです。぀たり、connector はログずしおデヌタを受け取っおメトリクスずしお出力したり、あるパむプラむンからメトリクスを受け取っお芳枬したデヌタに基づくメトリクスを提䟛したりできたす。 + +connector が解決するビゞネスケヌスは以䞋のずおりです。 + +- 異なるテレメトリヌタむプ間の倉換 + - logs から metrics ぞ + - traces から metrics ぞ + - metrics から logs ぞ +- 受信デヌタを芳枬し、独自のデヌタを生成 + - メトリクスを受け取っお、そのデヌタの分析メトリクスを生成する + +[Processor Overview](../4-processors) の **Ninja** セクションで簡単な抂芁を玹介しおいたすので、新しい connector コンポヌネントの远加状況に぀いおもプロゞェクトを必ず確認しおください。 +{{% /tab %}} +{{% /tabs %}} + +これらのコンポヌネント抂芁から、Jenkins 甚には pull 型の receiver を開発するこずが明らかです。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md new file mode 100644 index 0000000000..4ca8113ab6 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md @@ -0,0 +1,247 @@ +--- +title: OpenTelemetry Collector Development +linkTitle: 8.4 Designing the Metrics +weight: 12 +--- + +### メトリクスの蚭蚈 + +レシヌバヌで収集するメトリクスを定矩しお゚クスポヌトしやすくするため、[**mdatagen**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/mdatagen) を䜿甚したす。これは、YAML で定矩したメトリクスをコヌドに倉換するために Collector 向けに開発されたツヌルです。 + +{{% tabs %}} +{{% tab title="metadata.yaml"%}} + +``` yaml +--- +# Type defines the name to reference the component +# in the configuration file +type: jenkins + +# Status defines the component type and the stability level +status: + class: receiver + stability: + development: [metrics] + +# Attributes are the expected fields reported +# with the exported values. +attributes: + job.name: + description: The name of the associated Jenkins job + type: string + job.status: + description: Shows if the job had passed, or failed + type: string + enum: + - failed + - success + - unknown + +# Metrics defines all the pontentially exported values from this receiver. +metrics: + jenkins.jobs.count: + enabled: true + description: Provides a count of the total number of configured jobs + unit: "{Count}" + gauge: + value_type: int + jenkins.job.duration: + enabled: true + description: Show the duration of the job + unit: "s" + gauge: + value_type: int + attributes: + - job.name + - job.status + jenkins.job.commit_delta: + enabled: true + description: The calculation difference of the time job was finished minus commit timestamp + unit: "s" + gauge: + value_type: int + attributes: + - job.name + - job.status +``` + +{{% /tab %}} +{{% tab title="gen.go" %}} + +``` go +// To generate the additional code needed to capture metrics, +// the following command to be run from the shell: +// go generate -x ./... + +//go:generate go run github.com/open-telemetry/opentelemetry-collector-contrib/cmd/mdatagen@v0.80.0 metadata.yaml +package jenkinscireceiver + +// There is no code defined within this file. +``` + +{{% /tab%}} +{{% /tabs %}} + +次のセクションに進む前に、これらのファむルをプロゞェクトフォルダ内に䜜成しおください。 + +## Factory の構築 + +Factory は、提䟛された蚭定に基づいおオブゞェクトこのケヌスでは `jenkinscireceiver`を動的に生成できるようにする゜フトりェアデザむンパタヌンです。より身近な䟋で説明するず、携垯電話ショップに行き、自分の垌望に合った電話を䌝え、それを店員から枡しおもらうようなものです。 + +`go generate -x ./...` コマンドを実行するず、新しいフォルダ `jenkinscireceiver/internal/metadata` が䜜成され、定矩されたメトリクスを゚クスポヌトするために必芁なすべおのコヌドが生成されたす。必芁なコヌドは次のずおりです。 + +{{% tabs %}} +{{% tab title="factory.go" %}} + +``` go +package jenkinscireceiver + +import ( + "errors" + + "go.opentelemetry.io/collector/component" + "go.opentelemetry.io/collector/config/confighttp" + "go.opentelemetry.io/collector/receiver" + "go.opentelemetry.io/collector/receiver/scraperhelper" + + "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata" +) + +func NewFactory() receiver.Factory { + return receiver.NewFactory( + metadata.Type, + newDefaultConfig, + receiver.WithMetrics(newMetricsReceiver, metadata.MetricsStability), + ) +} + +func newMetricsReceiver(_ context.Context, set receiver.CreateSettings, cfg component.Config, consumer consumer.Metrics) (receiver.Metrics, error) { + // Convert the configuration into the expected type + conf, ok := cfg.(*Config) + if !ok { + return nil, errors.New("can not convert config") + } + sc, err := newScraper(conf, set) + if err != nil { + return nil, err + } + return scraperhelper.NewScraperControllerReceiver( + &conf.ScraperControllerSettings, + set, + consumer, + scraperhelper.AddScraper(sc), + ) +} +``` + +{{% /tab %}} +{{% tab title="config.go" %}} + +``` go +package jenkinscireceiver + +import ( + "go.opentelemetry.io/collector/config/confighttp" + "go.opentelemetry.io/collector/receiver/scraperhelper" + + "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata" +) + +type Config struct { + // HTTPClientSettings contains all the values + // that are commonly shared across all HTTP interactions + // performed by the collector. + confighttp.HTTPClientSettings `mapstructure:",squash"` + // ScraperControllerSettings will allow us to schedule + // how often to check for updates to builds. + scraperhelper.ScraperControllerSettings `mapstructure:",squash"` + // MetricsBuilderConfig contains all the metrics + // that can be configured. + metadata.MetricsBuilderConfig `mapstructure:",squash"` +} + +func newDefaultConfig() component.Config { + return &Config{ + ScraperControllerSettings: scraperhelper.NewDefaultScraperControllerSettings(metadata.Type), + HTTPClientSettings: confighttp.NewDefaultHTTPClientSettings(), + MetricsBuilderConfig: metadata.DefaultMetricsBuilderConfig(), + } +} +``` + +{{% /tab %}} +{{% tab title="scraper.go" %}} + +``` go +package jenkinscireceiver + +type scraper struct {} + +func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) { + // Create a our scraper with our values + s := scraper{ + // To be filled in later + } + return scraperhelper.NewScraper(metadata.Type, s.scrape) +} + +func (scraper) scrape(ctx context.Context) (pmetric.Metrics, error) { + // To be filled in + return pmetrics.NewMetrics(), nil +} +``` + +{{% /tab %}} +{{% tab title="build-config.yaml" %}} + +``` yaml +--- +dist: + name: otelcol + description: "Conf workshop collector" + output_path: ./dist + version: v0.0.0-experimental + +extensions: + - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/basicauthextension v0.80.0 + - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0 + +receivers: + - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0 + - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0 + - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0 + - gomod: splunk.conf/workshop/example/jenkinscireceiver v0.0.0 + path: ./jenkinscireceiver + +processors: + - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0 + +exporters: + - gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0 + - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0 + - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.80.0 + +# This replace is a go directive that allows for redefine +# where to fetch the code to use since the default would be from a remote project. +replaces: +- splunk.conf/workshop/example/jenkinscireceiver => ./jenkinscireceiver +``` + +{{% /tab %}} +{{% tab title="project layout" %}} + +``` text +├── build-config.yaml +└── jenkinscireceiver + ├── go.mod + ├── config.go + ├── factory.go + ├── scraper.go + └── internal + └── metadata +``` + +{{% /tab %}} +{{% /tabs %}} + +これらのファむルを期埅される内容でプロゞェクトに曞き蟌んだら、`go mod tidy` を実行しおください。これによりすべおのリモヌト䟝存関係が取埗され、`go.mod` が曎新されお `go.sum` ファむルが生成されたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md new file mode 100644 index 0000000000..ffe78ed15f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md @@ -0,0 +1,224 @@ +--- +title: OpenTelemetry Collector Development +linkTitle: 8.5 Building Business Logic +weight: 13 +--- + +## ビゞネスロゞックの構築 + +珟時点では、ただ䜕も凊理を行わないカスタムコンポヌネントがあるだけなので、Jenkins からデヌタを取埗するために必芁なロゞックを远加する必芁がありたす。 + +ここから先に行う手順は次のずおりです。 + +1. Jenkins に接続するクラむアントを䜜成する +1. 蚭定されおいるすべおのゞョブを取埗する +1. 蚭定されたゞョブの盎近のビルドのステヌタスをレポヌトする +1. コミットのタむムスタンプずゞョブ完了時刻の差を蚈算する + +倉曎は `scraper.go` に察しお行いたす。 + +{{% tabs %}} +{{% tab title="1. Add Jenkins client" %}} + +Jenkins サヌバヌに接続するために、Jenkins サヌバヌからデヌタを読み取るのに必芁な機胜を提䟛するパッケヌゞ ["github.com/yosida95/golang-jenkins"](https://pkg.go.dev/github.com/yosida95/golang-jenkins) を䜿甚したす。 + +さらに、["go.opentelemetry.io/collector/receiver/scraperhelper"](https://pkg.go.dev/go.opentelemetry.io/collector/receiver/scraperhelper) ラむブラリのヘルパヌ関数を掻甚しお、コンポヌネントの起動が完了した時点で Jenkins サヌバヌに接続できるよう、start 関数を䜜成したす。 + +```go +package jenkinscireceiver + +import ( + "context" + + jenkins "github.com/yosida95/golang-jenkins" + "go.opentelemetry.io/collector/component" + "go.opentelemetry.io/collector/pdata/pmetric" + "go.opentelemetry.io/collector/receiver" + "go.opentelemetry.io/collector/receiver/scraperhelper" + + "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata" +) + +type scraper struct { + mb *metadata.MetricsBuilder + client *jenkins.Jenkins +} + +func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) { + s := &scraper{ + mb : metadata.NewMetricsBuilder(cfg.MetricsBuilderConfig, set), + } + + return scraperhelper.NewScraper( + metadata.Type, + s.scrape, + scraperhelper.WithStart(func(ctx context.Context, h component.Host) error { + client, err := cfg.ToClient(h, set.TelemetrySettings) + if err != nil { + return err + } + // The collector provides a means of injecting authentication + // on our behalf, so this will ignore the libraries approach + // and use the configured http client with authentication. + s.client = jenkins.NewJenkins(nil, cfg.Endpoint) + s.client.SetHTTPClient(client) + return nil + }), + ) +} + +func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) { + // To be filled in + return pmetric.NewMetrics(), nil +} + +``` + +これで Jenkins receiver の初期化に必芁なセットアップコヌドはすべお完了です。 +{{% /tab%}} +{{% tab title="2. Capture all configured jobs" %}} + +ここからは、これたで未実装のたたになっおいた `scrape` メ゜ッドに焊点を圓おおいきたす。このメ゜ッドは、蚭定で指定された間隔デフォルトでは1分ごずで実行されたす。 + +蚭定枈みのゞョブ数を取埗したい理由は、Jenkins サヌバヌの成長を可芖化し、どれだけのプロゞェクトがオンボヌディングされたかを枬定するためです。これを実珟するために、jenkins クラむアントを呌び出しおすべおのゞョブを䞀芧衚瀺したす。゚ラヌが返された堎合はメトリクスを返さずにその゚ラヌを返し、それ以倖の堎合は metric builder からデヌタを発行したす。 + +```go +func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) { + jobs, err := s.client.GetJobs() + if err != nil { + return pmetric.Metrics{}, err + } + + // Recording the timestamp to ensure + // all captured data points within this scrape have the same value. + now := pcommon.NewTimestampFromTime(time.Now()) + + // Casting to an int64 to match the expected type + s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs))) + + // To be filled in + + return s.mb.Emit(), nil +} +``` + +{{% /tab%}} +{{% tab title="3. Report the status of each job" %}} + +前のステップでは、すべおのゞョブを取埗しお、その個数をレポヌトできるようにしたした。このステップでは、各ゞョブを調査し、レポヌトされた倀からメトリクスを取埗したす。 + +```go +func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) { + jobs, err := s.client.GetJobs() + if err != nil { + return pmetric.Metrics{}, err + } + + // Recording the timestamp to ensure + // all captured data points within this scrape have the same value. + now := pcommon.NewTimestampFromTime(time.Now()) + + // Casting to an int64 to match the expected type + s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs))) + + for _, job := range jobs { + // Ensure we have valid results to start off with + var ( + build = job.LastCompletedBuild + status = metadata.AttributeJobStatusUnknown + ) + + // This will check the result of the job, however, + // since the only defined attributes are + // `success`, `failure`, and `unknown`. + // it is assume that anything did not finish + // with a success or failure to be an unknown status. + + switch build.Result { + case "aborted", "not_built", "unstable": + status = metadata.AttributeJobStatusUnknown + case "success": + status = metadata.AttributeJobStatusSuccess + case "failure": + status = metadata.AttributeJobStatusFailed + } + + s.mb.RecordJenkinsJobDurationDataPoint( + now, + int64(job.LastCompletedBuild.Duration), + job.Name, + status, + ) + } + + return s.mb.Emit(), nil +} +``` + +{{% /tab%}} +{{% tab title="4. Report the delta" %}} + +最埌のステップでは、コミットからゞョブ完了たでにかかった時間を蚈算し、DORA メトリクスを掚定するのに圹立おたす。 + +```go +func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) { + jobs, err := s.client.GetJobs() + if err != nil { + return pmetric.Metrics{}, err + } + + // Recording the timestamp to ensure + // all captured data points within this scrape have the same value. + now := pcommon.NewTimestampFromTime(time.Now()) + + // Casting to an int64 to match the expected type + s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs))) + + for _, job := range jobs { + // Ensure we have valid results to start off with + var ( + build = job.LastCompletedBuild + status = metadata.AttributeJobStatusUnknown + ) + + // Previous step here + + // Ensure that the `ChangeSet` has values + // set so there is a valid value for us to reference + if len(build.ChangeSet.Items) == 0 { + continue + } + + // Making the assumption that the first changeset + // item is the most recent change. + change := build.ChangeSet.Items[0] + + // Record the difference from the build time + // compared against the change timestamp. + s.mb.RecordJenkinsJobCommitDeltaDataPoint( + now, + int64(build.Timestamp-change.Timestamp), + job.Name, + status, + ) + } + + return s.mb.Emit(), nil +} +``` + +{{% /tab%}} +{{% /tabs %}} + +これらの手順をすべお完了するず、カスタムの Jenkins CI receiver の構築が完了です + +## 次は䜕でしょうか + +このコンポヌネントに察しお、他にも欲しい機胜が思い浮かぶかもしれたせん。たずえば次のようなものです。 + +- ゞョブで䜿甚されたブランチ名を含めるこずはできたすか +- ゞョブのプロゞェクト名を含めるこずはできたすか +- プロゞェクト党䜓のゞョブ実行時間を合蚈するにはどうすればよいでしょうか +- 倉曎が動䜜するこずをどのように怜蚌すればよいでしょうか + +ぜひこの時間を䜿っお、いろいろ詊したり、あえお壊しおみたり、蚭定を倉曎しおみたり、さらにはビルドからログを取埗するこずにも挑戊しおみおください。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md new file mode 100644 index 0000000000..6e38a6e4f6 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md @@ -0,0 +1,37 @@ +--- +title: OpenTelemetry Collector の開発 +linkTitle: 8. Develop +weight: 8 +--- + +## カスタムコンポヌネントの開発 + +Open Telemetry Collector のコンポヌネントを構築するには、3 ぀の重芁な芁玠が必芁です。 + +1. Configuration - _ナヌザヌが蚭定するために公開される倀_ +1. Factory - _提䟛された倀を甚いおコンポヌネントを生成する_ +1. Business Logic - _コンポヌネントが実行すべき凊理_ + +ここでは、プロゞェクトの重芁な DevOps メトリクスを远跡できるように、Jenkins ず連携するコンポヌネントを構築する䟋を䜿甚したす。 + +枬定察象ずしたいメトリクスは次のずおりです。 + +1. Lead time for changes - _「コミットが本番環境に到達するたでにかかる時間」_ +1. Change failure rate - _「本番環境で障害を匕き起こすデプロむの割合」_ +1. Deployment frequency - _「[チヌム] が本番環境にリリヌスする頻床」_ +1. Mean time to recover - _「[チヌム] が本番環境の障害から埩旧するたでにかかる時間」_ + +これらの指暙は、゜フトりェア開発チヌムのパフォヌマンスを瀺すために、Google の DevOps Research and Assesment (DORA)[^1] チヌムによっお特定されたした。_Jenkins CI_ を遞んだ理由は、同じオヌプン゜ヌス゜フトりェアの゚コシステムにずどたるこずで、将来的にベンダヌが管理する CI ツヌルが採甚する際の䟋ずしお圹立おられるためです。 + +## Instrument ず Component の比范 + +組織における Observability のレベルを向䞊させる際には、いく぀かのトレヌドオフが生じるため、考慮すべき点がありたす。 + +| | 長所 | 短所 | +| ----- | ----- | ----- | +| **(Auto) Instrumented** | システムを芳枬するために倖郚 API を監芖する必芁がない。 | 蚈装を倉曎するにはプロゞェクトぞの倉曎が必芁ずなる。 | +| | システムのオヌナヌや開発者が Observability を倉曎できる。 | 远加のランタむム䟝存関係が必芁ずなる。 | +| | システムのコンテキストを理解し、取埗したデヌタを _Exemplars_ ず関連付けるこずができる。 | システムのパフォヌマンスに圱響を䞎える可胜性がある。 | +| **Component** | - デヌタ名やセマンティクスの倉曎を、システムのリリヌスサむクルずは独立しお展開できる。 | 砎壊的な API 倉曎には、システムず collector の間で連携したリリヌスが必芁ずなる。 | +| | 収集デヌタの曎新や拡匵は、ナヌザヌから芋おシヌムレスな倉曎ずなる。 | 取埗したデヌタのセマンティクスが、新しいシステムリリヌスず敎合せずに予期せず壊れるこずがある。 | +| | 支揎チヌムが Observability の実践に぀いお深く理解しおいる必芁がない。 | システムから衚に出せるのは、厳密に倖郚公開されおいる情報に限られる。 | diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md new file mode 100644 index 0000000000..57d8fd2348 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md @@ -0,0 +1,79 @@ +--- +title: OpenTelemetry でオブザヌバビリティをクラりドネむティブに +linkTitle: OpenTelemetry Collector の抂念 +weight: 1 +description: OpenTelemetry Collector の抂念ず、Splunk Observability Cloud にデヌタを送信するための䜿い方を孊びたす。 +authors: ["Robert Castley"] +time: 1 hour +--- + +## 抂芁 + +OpenTelemetry を䜿い始める組織は、たずオブザヌバビリティバック゚ンドにデヌタを盎接送信するこずから着手するかもしれたせん。これは初期テストには適しおいたすが、オブザヌバビリティアヌキテクチャの䞀郚ずしお OpenTelemetry collector を利甚するず倚くのメリットがあり、本番環境のデプロむメントには掚奚されるアプロヌチです。 + +このワヌクショップでは、OpenTelemetry collector の利甚に焊点を圓お、Splunk Observability Cloud で利甚するための receivers、processors、exporters の蚭定の基瀎から始めたす。このワヌクショップを通じお、参加者は初心者から、分散プラットフォヌムのビゞネス䞊のオブザヌバビリティニヌズを解決するためにカスタムコンポヌネントを远加できるレベルぞず成長するこずができたす。 + +### Ninja セクション + +ワヌクショップ党䜓を通じお、展開可胜な {{% badge style=primary icon=user-ninja %}}**Ninja** セクション{{% /badge %}}が甚意されおいたす。これらはより実践的で、さらに螏み蟌んだ技術的な詳现に぀いお解説しおおり、ワヌクショップ䞭たたはご自身のお時間に合わせお探求しおいただけたす。 + +OpenTelemetry プロゞェクトは頻繁に開発が進められおいるため、これらのセクションの内容は叀くなっおいる可胜性がある点にご泚意ください。詳现が同期しおいない堎合に備えおリンクを提䟛したすので、曎新が必芁な箇所を芋぀けた堎合はお知らせください。 + +--- + +{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** 自分を詊そう{{% /badge %}}" %}} +**このワヌクショップを完了すれば、あなたは正匏に OpenTelemetry Collector の Ninja です** +{{% /expand %}} + +--- + +## 察象者 + +このむンタラクティブなワヌクショップは、OpenTelemetry Collector のアヌキテクチャずデプロむメントに぀いおさらに孊びたい開発者およびシステム管理者を察象ずしおいたす。 + +## 前提条件 + +- 参加者はデヌタ収集に぀いお基本的な理解があるこず +- コマンドラむンおよび vim/vi の経隓があるこず +- Ubuntu 20.04 LTS たたは 22.04 LTS が動䜜するむンスタンス/ホスト/VM + - 最小芁件は AWS/EC2 t2.micro1 CPU、1GB RAM、8GB ストレヌゞ + +## 孊習目暙 + +このワヌクショップを終えるたでに、参加者は以䞋のこずができるようになりたす + +- OpenTelemetry のコンポヌネントを理解する +- receivers、processors、exporters を䜿甚しおデヌタを収集・分析する +- OpenTelemetry を䜿甚するメリットを把握する +- ビゞネスニヌズを解決するためのカスタムコンポヌネントを構築する + +## OpenTelemetry のアヌキテクチャ + +{{< mermaid >}} +%%{ + init:{ + "theme":"base", + "themeVariables": { + "primaryColor": "#ffffff", + "clusterBkg": "#eff2fb", + "defaultLinkColor": "#333333" + } + } +}%% + +flowchart LR; + subgraph Collector + A[OTLP] --> M(Receivers) + B[JAEGER] --> M(Receivers) + C[Prometheus] --> M(Receivers) + end + subgraph Processors + M(Receivers) --> H(Filters, Attributes, etc) + E(Extensions) + end + subgraph Exporters + H(Filters, Attributes, etc) --> S(OTLP) + H(Filters, Attributes, etc) --> T(JAEGER) + H(Filters, Attributes, etc) --> U(Prometheus) + end +{{< /mermaid >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md new file mode 100644 index 0000000000..16ac0c0f59 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md @@ -0,0 +1,60 @@ +--- +title: 1.1 Validation & Load Generation +linkTitle: 1.1 Validation & Load Generation +weight: 1 +--- + +このワヌクショップでは、[**https://otelbin.io**](https://otelbin.io/) を䜿甚しお YAML 構文を玠早く怜蚌し、OpenTelemetry の構成が正確であるこずを確認したす。このステップは、セッション䞭にテストを実行する前に゚ラヌを回避するのに圹立ちたす。 + +{{% notice title="Exercise" style="green" icon="running" %}} +構成を怜蚌する方法は次のずおりです。 + +1. [**https://otelbin.io**](https://otelbin.io/) を開き、巊ペむンに YAML を貌り付けお既存の構成を眮き換えたす。 + > [!INFO] + > Mac を䜿甚しおおり、Splunk Workshop むンスタンスを䜿甚しおいない堎合は、次のコマンドを実行するこずで、`agent.yaml` ファむルの内容を玠早くクリップボヌドにコピヌできたす。 + > + > ```bash + > cat agent.yaml | pbcopy + > ``` + +2. ペヌゞの䞊郚で、怜蚌察象ずしお **Splunk OpenTelemetry Collector** が遞択されおいるこずを確認しおください。このオプションを遞択し**ない**堎合、UI に `Receiver "hostmetrics" is unused. (Line 8)` ずいう譊告が衚瀺されたす。 + +3. 怜蚌が完了したら、以䞋の画像衚珟を参照しお、パむプラむンが正しく蚭定されおいるこずを確認しおください。 + +ほずんどの堎合、**䞻芁なパむプラむン**のみを衚瀺したす。ただし、3 ぀のパむプラむン (Traces、Metrics、Logs) すべおが同じ構造を共有しおいる堎合は、それぞれを個別に瀺すのではなく、その旚を蚘茉したす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + EXP1( debug 
fa:fa-upload):::exporter + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1[**Traces/Metrics/Logs**] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fff,stroke-width:1px, color:#fff,stroke-dasharray: 3 3; +``` + +{{% /notice %}} + +--- + +## Load Generation Tool + +このワヌクショップのために、`loadgen` ツヌルを特別に開発したした。`loadgen` は、トレヌスおよびロギングアクティビティをシミュレヌトするための柔軟な負荷生成ツヌルです。デフォルトで base、health、security のトレヌスをサポヌトし、オプションでランダムな匕甚をプレヌンテキストたたは JSON 圢匏でファむルにロギングする機胜も備えおいたす。 + +`loadgen` によっお生成される出力は、OpenTelemetry むンストルメンテヌションラむブラリによっお生成されるものを暡倣しおおり、Collector の凊理ロゞックをテストするこずを可胜にし、珟実のシナリオを暡倣するためのシンプルか぀匷力な方法を提䟛したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md new file mode 100644 index 0000000000..1d0235644c --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md @@ -0,0 +1,95 @@ +--- +title: 1.2 Test Agent Configuration +linkTitle: 1.2 Test Agent Configuration +weight: 2 +--- + +新しく䜜成した `agent.yaml` を䜿っお OpenTelemetry Collector を起動する準備が敎いたした。この挔習では、OpenTelemetry Collector を通じおデヌタがどのように流れおいくのかを理解するための基瀎を築きたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent を起動する**: **Agent terminal** りィンドりで次のコマンドを実行したす。 + +```bash { title="Start Collector" } +../otelcol --config=agent.yaml +``` + +**デバッグ出力を確認する**: すべおが正しく構成されおいれば、出力の最初ず最埌の行は次のようになりたす。 + +```text +2025/01/13T12:43:51 settings.go:478: Set config to [agent.yaml] + +2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data. +``` + +**テスト甚 Span を送信する**: アプリケヌションを蚈装する代わりに、`loadgen` ツヌルを䜿っお OpenTelemetry Collector ぞトレヌスデヌタを送信する動䜜をシミュレヌトしたす。 + +**Spans terminal** りィンドりで `1-agent` ディレクトリに移動し、次のコマンドを実行しお Span を 1 件送信したす。 + +{{% tabs %}} +{{% tab title="Start Load Generator" %}} + +```bash +../loadgen -count 1 +``` + +{{% /tab %}} +{{% tab title="Load Generator Output" %}} + +```text +Sending traces. Use Ctrl-C to stop. +Response: {"partialSuccess":{}} + +Base trace sent with traceId: 1aacb1db8a6d510f10e52f154a7fdb90 and spanId: 7837a3a2d3635d9f + ``` + +`{"partialSuccess":{}}`: `partialSuccess` フィヌルドが空であるため、100% 成功したこずを瀺しおいたす。䞀郚が倱敗した堎合は、このフィヌルドに倱敗した郚分の詳现が含たれたす。 + +{{% /tab %}} +{{% /tabs %}} + +**デバッグ出力を確認する**: + +**Agent terminal** りィンドりで Collector のデバッグ出力を確認したす。 + +```text +2025-03-06T10:11:35.174Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1} +2025-03-06T10:11:35.174Z info ResourceSpans #0 +Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 +Resource attributes: + -> service.name: Str(cinema-service) + -> deployment.environment: Str(production) + -> host.name: Str(workshop-instance) + -> os.type: Str(linux) + -> otelcol.service.mode: Str(agent) +ScopeSpans #0 +ScopeSpans SchemaURL: +InstrumentationScope cinema.library 1.0.0 +InstrumentationScope attributes: + -> fintest.scope.attribute: Str(Starwars, LOTR) +Span #0 + Trace ID : 0ef4daa44a259a7199a948231bc383c0 + Parent ID : + ID : e8fdd442c36cbfb1 + Name : /movie-validator + Kind : Server + Start time : 2025-03-06 10:11:35.163557 +0000 UTC + End time : 2025-03-06 10:11:36.163557 +0000 UTC + Status code : Ok + Status message : Success +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(86.48) + {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"} +``` + +> [!IMPORTANT] +> **Agent terminal** りィンドりで `Ctrl-C` を䜿っお `agent` を停止したす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md new file mode 100644 index 0000000000..b7d605dd9b --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md @@ -0,0 +1,188 @@ +--- +title: 1.3.1 File Exporter のテスト +linkTitle: 1.3.1 File Exporter のテスト +weight: 1 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent を再起動する**: **Agent タヌミナル** りィンドりを開き、倉曎した構成を䜿っお `agent` を (再) 起動したす。 + +{{% tabs %}} +{{% tab title="Start the Agent" %}} + +```bash +../otelcol --config=agent.yaml +``` + +{{% /tab %}} +{{% tab title="Agent Output" %}} + +```text +2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data. +``` + +{{% /tab %}} +{{% /tabs %}} + +**トレヌスを送信する**: **Spans タヌミナル** りィンドりから別のスパンを送信し、これたでず同じ出力がコン゜ヌルに衚瀺されるこずを確認したす。 + +```bash { title="Start Load Generator" } +../loadgen -count 1 +``` + +ここで **Agent タヌミナル** りィンドりの `agent` を `Ctrl-C` で停止し、`agent.out` ファむルが曞き出されたこずを確認できるようにしたす。 + +**`agent.out` ファむルが曞き出されたこずを確認する**: 珟圚のディレクトリに `agent.out` ずいう名前のファむルが曞き出されおいるか確認したす。 + +```text { title="Updated Directory Structure" } +. +├── agent.out # OTLP/Json output created by the File Exporter +└── agent.yaml +``` + +**スパンの圢匏を確認する**: + +1. File Exporter が `agent.out` にスパンを曞き出す際に䜿甚する圢匏を確認したす。 +2. 出力は **OTLP/JSON** 圢匏の 1 行になりたす。 +3. `agent.out` の内容を衚瀺するには、`cat ./agent.out` コマンドを䜿甚できたす。より読みやすい敎圢枈みの衚瀺にするには、`cat ./agent.out | jq` のように `jq` に出力をパむプしおください。 + +{{% tabs %}} +{{% tab title="cat ./agent.out" %}} + +```json +{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"cinema-service"}},{"key":"deployment.environment","value":{"stringValue":"production"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"agent"}}]},"scopeSpans":[{"scope":{"name":"cinema.library","version":"1.0.0","attributes":[{"key":"fintest.scope.attribute","value":{"stringValue":"Starwars, LOTR"}}]},"spans":[{"traceId":"d824a28db5aa5f5a3011f19c452e5af0","spanId":"ab4cde146f77eacf","parentSpanId":"","name":"/movie-validator","kind":2,"startTimeUnixNano":"1741256991405300000","endTimeUnixNano":"1741256992405300000","attributes":[{"key":"user.name","value":{"stringValue":"George Lucas"}},{"key":"user.phone_number","value":{"stringValue":"+1555-867-5309"}},{"key":"user.email","value":{"stringValue":"george@deathstar.email"}},{"key":"user.password","value":{"stringValue":"LOTR>StarWars1-2-3"}},{"key":"user.visa","value":{"stringValue":"4111 1111 1111 1111"}},{"key":"user.amex","value":{"stringValue":"3782 822463 10005"}},{"key":"user.mastercard","value":{"stringValue":"5555 5555 5555 4444"}},{"key":"payment.amount","value":{"doubleValue":56.24}}],"status":{"message":"Success","code":1}}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]} +``` + +{{% /tab %}} +{{% tab title="cat ./agent.out | jq" %}} + +```json +{ + "resourceSpans": [ + { + "resource": { + "attributes": [ + { + "key": "service.name", + "value": { + "stringValue": "cinema-service" + } + }, + { + "key": "deployment.environment", + "value": { + "stringValue": "production" + } + }, + { + "key": "host.name", + "value": { + "stringValue": "RCASTLEY-M-YQRY.local" + } + }, + { + "key": "os.type", + "value": { + "stringValue": "darwin" + } + }, + { + "key": "otelcol.service.mode", + "value": { + "stringValue": "agent" + } + } + ] + }, + "scopeSpans": [ + { + "scope": { + "name": "cinema.library", + "version": "1.0.0", + "attributes": [ + { + "key": "fintest.scope.attribute", + "value": { + "stringValue": "Starwars, LOTR" + } + } + ] + }, + "spans": [ + { + "traceId": "d824a28db5aa5f5a3011f19c452e5af0", + "spanId": "ab4cde146f77eacf", + "parentSpanId": "", + "name": "/movie-validator", + "kind": 2, + "startTimeUnixNano": "1741256991405300000", + "endTimeUnixNano": "1741256992405300000", + "attributes": [ + { + "key": "user.name", + "value": { + "stringValue": "George Lucas" + } + }, + { + "key": "user.phone_number", + "value": { + "stringValue": "+1555-867-5309" + } + }, + { + "key": "user.email", + "value": { + "stringValue": "george@deathstar.email" + } + }, + { + "key": "user.password", + "value": { + "stringValue": "LOTR>StarWars1-2-3" + } + }, + { + "key": "user.visa", + "value": { + "stringValue": "4111 1111 1111 1111" + } + }, + { + "key": "user.amex", + "value": { + "stringValue": "3782 822463 10005" + } + }, + { + "key": "user.mastercard", + "value": { + "stringValue": "5555 5555 5555 4444" + } + }, + { + "key": "payment.amount", + "value": { + "doubleValue": 56.24 + } + } + ], + "status": { + "message": "Success", + "code": 1 + } + } + ] + } + ], + "schemaUrl": "https://opentelemetry.io/schemas/1.6.1" + } + ] +} +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md new file mode 100644 index 0000000000..b966bd73cc --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md @@ -0,0 +1,97 @@ +--- +title: 1.3 File Exporter +linkTitle: 1.3 File Exporter +weight: 2 +--- + +画面䞊のデバッグ出力だけでなく、パむプラむンの゚クスポヌトフェヌズでも出力を生成したい堎合がありたす。そのために、比范甚に OTLP デヌタをファむルぞ曞き出す **File Exporter** を远加したす。 + +OpenTelemetry の **debug exporter** ず **file exporter** の違いは、甚途ず出力先にありたす。 + +| 機胜 | Debug Exporter | File Exporter | +|-----------------|--------------------------|-------------------------| +| **出力先** | コン゜ヌルログ | ディスク䞊のファむル | +| **甹途** | リアルタむムデバッグ | 氞続的なオフラむン分析 | +| **適した甚途** | テスト䞭の玠早い確認 | 䞀時的な保存ず共有 | +| **本番利甚** | 䞍可 | 皀だが可胜 | +| **氞続性** | なし | あり | + +たずめるず、**Debug Exporter** はリアルタむムの開発時トラブルシュヌティングに適しおおり、**File Exporter** はテレメトリデヌタをロヌカルに保存しお埌で利甚するのに適しおいたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent terminal** りィンドりで Collector が起動しおいないこずを確認しおから、`agent.yaml` を線集しお **File Exporter** を構成したす。 + +1. **`file` exporter の構成**: [**File Exporter**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/fileexporter/README.md) はテレメトリデヌタをディスク䞊のファむルに曞き出したす。 + + ```yaml + file: # File Exporter + path: "./agent.out" # Save path (OTLP/JSON) + append: false # Overwrite the file each time + ``` + +1. **Pipelines セクションの曎新**: `file` exporter を `traces` パむプラむンにのみ远加したす。 + + ```yaml + pipelines: + traces: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter processor + - resourcedetection # Add system attributes to the data + - resource/add_mode # Add collector mode metadata + exporters: + - debug # Debug Exporter + - file # File Exporter + metrics: + receivers: + - otlp + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + exporters: + - debug + logs: + receivers: + - otlp + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + exporters: + - debug + ``` + +{{% /notice %}} + +[**https://otelbin.io**](https://otelbin.io/) を䜿甚しお、agent の蚭定を怜蚌したす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2( file 
fa:fa-upload):::exporter + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> EXP1 + PRO3 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md new file mode 100644 index 0000000000..7a4c2bc2f5 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md @@ -0,0 +1,182 @@ +--- +title: 1.4.1 リ゜ヌスメタデヌタのテスト +linkTitle: 1.4.1 リ゜ヌスメタデヌタのテスト +weight: 1 +--- +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent を再起動する**: **Agent タヌミナル** りィンドりで、倉曎内容をテストするために曎新された蚭定を䜿っお `agent` を再起動したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +すべおが正しくセットアップされおいれば、出力の最埌の行で collector が皌働しおいるこずが確認できるはずです。 + +```text + 2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data. +``` + +**トレヌスを送信する**: **Spans タヌミナル** りィンドりから`1-agent` ディレクトリにいるこずを確認したうえで、`loadgen` バむナリで再床 span を送信し、新しい `agent.out` を䜜成したす。 + +```bash { title="Start Load Generator" } +../loadgen +``` + +**Agent のデバッグ出力を確認する**: `resource attributes` セクションに 3 ぀の新しい行`host.name`、`os.type`、`otelcol.service.mode`が衚瀺されおいるはずです。 + +```text + +Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 +Resource attributes: + -> service.name: Str(cinema.service) + -> deployment.environment: Str(production) + -> host.name: Str([MY_HOST_NAME]) + -> os.type: Str([MY_OS]) + -> otelcol.service.mode: Str(agent) + +``` + +**メタデヌタが span に远加されおいるこずを確認する**: `Ctrl-C` で `loadgen` を停止したす。新しい `agent.out` ファむルで以䞋を確認したす。 + +1. `resourceSpans` セクションに `otelcol.service.mode` 属性が存圚し、その倀が `agent` であるこずを確認したす。 +2. `resourcedetection` の属性`host.name` ず `os.type`も存圚するこずを確認したす。 + +これらの倀は、パむプラむンに蚭定された processor によっお、お䜿いのデバむスに基づいお自動的に远加されたす。 + +{{% tabs %}} +{{% tab title="cat ./agent.out" %}} + +```json +{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"cinema-service"}},{"key":"deployment.environment","value":{"stringValue":"production"}},{"key":"host.name","value":{"stringValue":"RCASTLEY-M-YQRY.local"}},{"key":"os.type","value":{"stringValue":"darwin"}},{"key":"otelcol.service.mode","value":{"stringValue":"agent"}}]},"scopeSpans":[{"scope":{"name":"cinema.library","version":"1.0.0","attributes":[{"key":"fintest.scope.attribute","value":{"stringValue":"Starwars, LOTR"}}]},"spans":[{"traceId":"ae921957a4d93fa11cee640cd7908eb8","spanId":"f6b0f29825efe585","parentSpanId":"","name":"/movie-validator","kind":2,"startTimeUnixNano":"1740994347431796000","endTimeUnixNano":"1740994348431796000","attributes":[{"key":"user.name","value":{"stringValue":"George Lucas"}},{"key":"user.phone_number","value":{"stringValue":"+1555-867-5309"}},{"key":"user.email","value":{"stringValue":"george@deathstar.email"}},{"key":"user.account_password","value":{"stringValue":"LOTR>StarWars1-2-3"}},{"key":"user.visa","value":{"stringValue":"4111 1111 1111 1111"}},{"key":"user.amex","value":{"stringValue":"3782 822463 10005"}},{"key":"user.mastercard","value":{"stringValue":"5555 5555 5555 4444"}}],"status":{"message":"Success","code":1}}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]} +``` + +{{% /tab %}} +{{% tab title="cat ./agent.out | jq" %}} + +```json +{ + "resourceSpans": [ + { + "resource": { + "attributes": [ + { + "key": "service.name", + "value": { + "stringValue": "cinema-service" + } + }, + { + "key": "deployment.environment", + "value": { + "stringValue": "production" + } + }, + { + "key": "host.name", + "value": { + "stringValue": "RCASTLEY-M-YQRY.local" + } + }, + { + "key": "os.type", + "value": { + "stringValue": "darwin" + } + }, + { + "key": "otelcol.service.mode", + "value": { + "stringValue": "agent" + } + } + ] + }, + "scopeSpans": [ + { + "scope": { + "name": "cinema.library", + "version": "1.0.0", + "attributes": [ + { + "key": "fintest.scope.attribute", + "value": { + "stringValue": "Starwars, LOTR" + } + } + ] + }, + "spans": [ + { + "traceId": "ab984cd113463aa919ac200751fcfc1d", + "spanId": "db651e116290a8f2", + "parentSpanId": "", + "name": "/movie-validator", + "kind": 2, + "startTimeUnixNano": "1740994462515044000", + "endTimeUnixNano": "1740994463515044000", + "attributes": [ + { + "key": "user.name", + "value": { + "stringValue": "George Lucas" + } + }, + { + "key": "user.phone_number", + "value": { + "stringValue": "+1555-867-5309" + } + }, + { + "key": "user.email", + "value": { + "stringValue": "george@deathstar.email" + } + }, + { + "key": "user.account_password", + "value": { + "stringValue": "LOTR>StarWars1-2-3" + } + }, + { + "key": "user.visa", + "value": { + "stringValue": "4111 1111 1111 1111" + } + }, + { + "key": "user.amex", + "value": { + "stringValue": "3782 822463 10005" + } + }, + { + "key": "user.mastercard", + "value": { + "stringValue": "5555 5555 5555 4444" + } + } + ], + "status": { + "message": "Success", + "code": 1 + } + } + ] + } + ], + "schemaUrl": "https://opentelemetry.io/schemas/1.6.1" + } + ] +} +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルりィンドりで `Ctrl-C` を䜿っお `agent` プロセスず `loadgen` プロセスを停止したす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md new file mode 100644 index 0000000000..8e97b06330 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md @@ -0,0 +1,90 @@ +--- +title: 1.4 Resource Metadata +linkTitle: 1.4 Resource Metadata +weight: 3 +hidden: true +--- + +ここたでは、OpenTelemetry Collector を経由するスパンをそのたた耇補しお゚クスポヌトしおきたした。 + +ここからは、プロセッサヌを䜿っおメタデヌタを远加し、ベヌスずなるスパンを充実させおいきたす。これらの远加情報は、トラブルシュヌティングや盞関分析に圹立ちたす。 + +{{% notice title="Exercise" style="green" icon="running" %}} +**Collector を停止する**: **Agent タヌミナル**りィンドりで `Ctrl-C` を抌し、実行䞭の Collector を停止しおください。`agent` が停止したら、`agent.yaml` を開きたす。 + +**すべおのパむプラむンを曎新する**: 䞡方のプロセッサヌ(`resourcedetection` ず `resource/add_mode`)を、**すべおのパむプラむン**の `processors` 配列に远加しおください。`memory_limiter` が最初のプロセッサヌであり続けるようにしおください。 + +- [**Resource Detection Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md) は、ホストからリ゜ヌス情報を怜出し、その情報をテレメトリデヌタのリ゜ヌス倀に远加たたは䞊曞きするために䜿甚されたす。 +- [**Resource Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourceprocessor/README.md) は、リ゜ヌス属性に倉曎を適甚するために䜿甚されたす。今回のデフォルト蚭定では、新しい属性 `otelcol.service.mode` を倀 `agent` で远加したす。 + +```yaml +service: # Services configured for this Collector + extensions: # Enabled extensions + - health_check + pipelines: # Array of configured pipelines + traces: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter Processor + - resourcedetection # Adds system attributes to the data + - resource/add_mode # Adds collector mode metadata + exporters: + - debug # Debug Exporter + - file # File Exporter + metrics: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter Processor + - resourcedetection # Adds system attributes to the data + - resource/add_mode # Adds collector mode metadata + exporters: + - debug # Debug Exporter + - file # File Exporter + logs: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter Processor + - resourcedetection # Adds system attributes to the data + - resource/add_mode # Adds collector mode metadata + exporters: + - debug # Debug Exporter + - file # File Exporter + +``` + +{{% /notice %}} + +これらのプロセッサヌを远加するこずで、システムのメタデヌタず Agent の動䜜モヌドでデヌタを充実させるこずができ、トラブルシュヌティングに圹立぀ほか、関連コンテンツに有甚なコンテキストを提䟛したす。 + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお Agent の蚭定を怜蚌しおください。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2( file 
fa:fa-upload):::exporter + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1[**Traces/Metrics/Logs**] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> EXP1 + PRO3 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fff,stroke-width:1px, color:#fff,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md new file mode 100644 index 0000000000..d2085a1b09 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md @@ -0,0 +1,107 @@ +--- +title: 1. Agent Configuration +linkTitle: 1. Agent Setup +time: 10 minutes +weight: 3 +--- + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +このワヌクショップでは、最倧 5 ぀のタヌミナルりィンドりを同時に䜿甚したす。敎理しやすくするため、各タヌミナルやシェルにそれぞれ固有の名前ず色を蚭定するこずをお勧めしたす。これにより、必芁に応じお玠早く識別し、切り替えるこずができたす。 + +これらのタヌミナルは、**Agent**、**Gateway**、**Spans**、**Logs**、**Tests** ず呌びたす。 +{{% /notice %}} + +{{% notice title="挔習" style="green" icon="running" %}} + +1. **Agent タヌミナル**りィンドりで `[WORKSHOP]` ディレクトリに移動し、`1-agent` ずいう名前の新しいサブディレクトリを䜜成したす。 + + ```bash + mkdir 1-agent && \ + cd 1-agent + ``` + +2. `agent.yaml` ずいう名前のファむルを䜜成したす。このファむルでは、OpenTelemetry Collector 蚭定の基本構造を定矩したす。 + +3. 以䞋の初期蚭定をコピヌしお `agent.yaml` に貌り付けたす。 + + ```yaml + # Extensions + extensions: + health_check: # Health Check Extension + endpoint: 0.0.0.0:13133 # Health Check Endpoint + + # Receivers + receivers: + hostmetrics: # Host Metrics Receiver + collection_interval: 3600s # Collection Interval (1hr) + scrapers: + cpu: # CPU Scraper + otlp: # OTLP Receiver + protocols: + http: # Configure HTTP protocol + endpoint: "0.0.0.0:4318" # Endpoint to bind to + + # Exporters + exporters: + debug: # Debug Exporter + verbosity: detailed # Detailed verbosity level + + # Processors + processors: + memory_limiter: # Limits memory usage + check_interval: 2s # Check interval + limit_mib: 512 # Memory limit in MiB + resourcedetection: # Resource Detection Processor + detectors: [system] # Detect system resources + override: true # Overwrites existing attributes + resource/add_mode: # Resource Processor + attributes: + - action: insert # Action to perform + key: otelcol.service.mode # Key name + value: "agent" # Key value + + # Connectors + #connectors: # leave this commented out; we will uncomment in an upcoming exercise + + # Service Section - Enabled Pipelines + service: + extensions: + - health_check # Health Check Extension + pipelines: + traces: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter processor + - resourcedetection # Add system attributes to the data + - resource/add_mode # Add collector mode metadata + exporters: + - debug # Debug Exporter + metrics: + receivers: + - otlp + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + exporters: + - debug + logs: + receivers: + - otlp + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + exporters: + - debug + ``` + +4. ディレクトリ構造は次のようになっおいるはずです。 + + ```text + . + └── agent.yaml # OpenTelemetry Collector configuration file + ``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md new file mode 100644 index 0000000000..b37f1d8740 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md @@ -0,0 +1,57 @@ +--- +title: 2.1 Start Gateway +linkTitle: 2.1 Start Gateway +weight: 1 +--- + +`gateway` の蚭定は、機胜させるために远加の蚭定倉曎を必芁ずしたせん。これは、時間を節玄し、**Gateway** の䞭栞ずなる抂念に集䞭するためです。 + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお `gateway` の蚭定を怜蚌したす。参考たでに、パむプラむンの `logs:` セクションは次のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resource
fa:fa-microchip
add_mode):::processor + PRO3(batch
fa:fa-microchip):::processor + EXP1( file 
fa:fa-upload
logs):::exporter + EXP2( debug 
fa:fa-upload):::exporter + %% Links + subID1:::sub-logs + subgraph " " + subgraph subID1[**Logs**] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> EXP2 + PRO3 --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +``` + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway の起動**: **Gateway タヌミナル** りィンドりで、次のコマンドを実行しお `gateway` を起動したす。 + +```bash {title="Start the Gateway"} +../otelcol --config=gateway.yaml +``` + +すべお正しく蚭定されおいれば、出力の最初ず最埌の行は次のようになりたす。 + +```text +2025/01/15 15:33:53 settings.go:478: Set config to [gateway.yaml] + +2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data. +``` + +{{% /notice %}} + +次に、新しく䜜成した `gateway` にデヌタを送信するように `agent` を蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md new file mode 100644 index 0000000000..8bd77ac14f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md @@ -0,0 +1,111 @@ +--- +title: 2.2 Configure Agent +linkTitle: 2.2 Configure Agent +weight: 2 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**`otlphttp` exporterを远加する**: [**OTLP/HTTP Exporter**](https://help.splunk.com/en/splunk-observability-cloud/manage-data/splunk-distribution-of-the-opentelemetry-collector/get-started-with-the-splunk-distribution-of-the-opentelemetry-collector/collector-components/exporters/otlphttp-exporter) は、**OTLP/HTTP** プロトコルを䜿甚しおagentからgatewayにデヌタを送信するために䜿甚されたす。 + +1. **Agentタヌミナル** りィンドりに切り替えたす。 +2. 新しく生成された `gateway-logs.out`、`gateway-metrics.out`、`gateway-traces.out` がディレクトリに存圚するこずを確認したす。 +3. ゚ディタで `agent.yaml` ファむルを開きたす。 +4. `exporters:` セクションに `otlphttp` exporterの蚭定を远加したす: + +```yaml + otlphttp: # Exporter Type + endpoint: "http://localhost:5318" # Gateway OTLP endpoint +``` + +**Batch Processorの蚭定を远加する**: [**Batch Processor**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md) は、span、metrics、たたはlogsを受け取り、それらをバッチにたずめたす。バッチ化するこずで、デヌタをより効率的に圧瞮し、デヌタ送信に必芁な送信接続の数を枛らすこずができたす。すべおのcollectorでbatch processorを蚭定するこずが匷く掚奚されたす。 + +1. `processors:` セクションに `batch` processorの蚭定を远加したす: + +```yaml + batch: # Processor Type +``` + +**Pipelinesを曎新する**: + +1. **Hostmetrics Receiverを有効化**: + - `metrics` pipelineに `hostmetrics` を远加したす。[**HostMetrics Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver#readme) は、珟圚の蚭定では1時間に1回ホストCPUメトリクスを生成したす。 +2. **Batch Processorを有効化**: + - `traces`、`metrics`、`logs` pipelineに`resource/add_mode` processorの埌に`batch` processorを远加したす。 +3. **OTLPHTTP Exporterを有効化**: + - `traces`、`metrics`、`logs` pipelineに `otlphttp` exporterを远加したす。 + +```yaml + pipelines: + traces: + receivers: + - otlp # OTLP Receiver + processors: + - memory_limiter # Memory Limiter processor + - resourcedetection # Add system attributes to the data + - resource/add_mode # Add collector mode metadata + - batch # Batch processor + exporters: + - debug # Debug Exporter + - file # File Exporter + - otlphttp # OTLP/HTTP Exporter + metrics: + receivers: + - otlp + - hostmetrics # Host Metrics Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + logs: + receivers: + - otlp + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp +``` + +{{% /notice %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しおagentの蚭定を怜蚌したす。参考たでに、pipelinesの `metrics:` セクションは次のようになりたす: + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(    otlp    
fa:fa-download):::receiver + REC2(hostmetrics
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(batch
fa:fa-microchip):::processor + EXP1(otlphttp
fa:fa-upload):::exporter + EXP2( debug 
fa:fa-upload):::exporter + %% Links + subID1:::sub-metrics + subgraph " " + subgraph subID1["`**Metrics**`"] + direction LR + REC1 --> PRO1 + REC2 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> PRO4 + PRO4 --> EXP2 + PRO4 --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md new file mode 100644 index 0000000000..7817c89acd --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md @@ -0,0 +1,77 @@ +--- +title: 2.3 Agent から Gateway ぞメトリクスを送信する +linkTitle: 2.3 Send Metrics +weight: 3 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent を起動する**: **Agent タヌミナル** りィンドりで、曎新された蚭定を䜿っお agent を起動したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**CPU メトリクスを確認する**: + +1. `agent` が起動したら、ただちに **CPU** メトリクスの送信を開始するこずを確認したす。 +2. `agent` ず `gateway` の䞡方が、デバッグ出力にこの動䜜を衚瀺したす。出力は次のスニペットのようになるはずです。 + +```text + +NumberDataPoints #37 +Data point attributes: + -> cpu: Str(cpu0) + -> state: Str(system) +StartTimestamp: 2024-12-09 14:18:28 +0000 UTC +Timestamp: 2025-01-15 15:27:51.319526 +0000 UTC +Value: 9637.660000 +``` + +この段階で、`agent` は 1 時間ごず、たたは再起動のたびに **CPU** メトリクスを収集し続け、それらを gateway に送信したす。 + +`gateway` はこれらのメトリクスを凊理し、`./gateway-metrics.out` ずいう名前のファむルに゚クスポヌトしたす。このファむルは、パむプラむンサヌビスの䞀郚ずしお゚クスポヌトされたメトリクスを保存したす。 + +**デヌタが Gateway に到達したこずを確認する**: CPU メトリクス、特に `cpu0` のメトリクスが gateway に正垞に到達したこずを確認するため、`jq` コマンドを䜿っお `gateway-metrics.out` ファむルを調査したす。 + +次のコマンドは、`system.cpu.time` メトリクスをフィルタリングしお抜出し、`cpu0` に焊点を圓おたす。メトリクスの state䟋: `user`、`system`、`idle`、`interrupt`ず察応する倀を衚瀺したす。 + +**Tests タヌミナル** で以䞋のコマンドを実行し、`system.cpu.time` メトリクスを確認したす。 + +{{% tabs %}} +{{% tab title="Check CPU Metrics" %}} + +```bash +jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.time") | .sum.dataPoints[] | select(.attributes[0].value.stringValue == "cpu0") | {cpu: .attributes[0].value.stringValue, state: .attributes[1].value.stringValue, value: .asDouble}' gateway-metrics.out +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{ + "cpu": "cpu0", + "state": "user", + "value": 123407.02 +} +{ + "cpu": "cpu0", + "state": "system", + "value": 64866.6 +} +{ + "cpu": "cpu0", + "state": "idle", + "value": 216427.87 +} +{ + "cpu": "cpu0", + "state": "interrupt", + "value": 0 +} +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md new file mode 100644 index 0000000000..cdd535a851 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md @@ -0,0 +1,92 @@ +--- +title: 2.4 Agent から Gateway ぞトレヌスを送信する +linkTitle: 2.4 トレヌスの送信 +weight: 4 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**テストトレヌスを送信する**: + +1. `agent` ず `gateway` がただ実行䞭であるこずを確認したす。 +2. **Spans terminal** りィンドりで、次のコマンドを実行しお 5 ぀のスパンを送信し、`agent` ず `gateway` のデバッグログの出力を怜蚌したす。 + +{{% tabs %}} +{{% tab title="Start the Load Generator" %}} + +```bash +../loadgen -count 5 +``` + +{{% /tab %}} +{{% tab title="Agent/Gateway Debug Output" %}} + +```text +2025-03-06T11:49:00.456Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1} +2025-03-06T11:49:00.456Z info ResourceSpans #0 +Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 +Resource attributes: + -> service.name: Str(cinema-service) + -> deployment.environment: Str(production) + -> host.name: Str(workshop-instance) + -> os.type: Str(linux) + -> otelcol.service.mode: Str(agent) +ScopeSpans #0 +ScopeSpans SchemaURL: +InstrumentationScope cinema.library 1.0.0 +InstrumentationScope attributes: + -> fintest.scope.attribute: Str(Starwars, LOTR) +Span #0 + Trace ID : 97fb4e5b13400b5689e3306da7cff077 + Parent ID : + ID : 413358465e5b4f15 + Name : /movie-validator + Kind : Server + Start time : 2025-03-06 11:49:00.431915 +0000 UTC + End time : 2025-03-06 11:49:01.431915 +0000 UTC + Status code : Ok + Status message : Success +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(87.01) + {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"} +``` + +{{% /tab %}} +{{% /tabs %}} + +**Gateway がスパンを凊理したこずを確認する**: Gateway は受信したスパンを凊理するず、トレヌスデヌタを `gateway-traces.out` ずいうファむルに曞き蟌みたす。スパンが正垞に凊理されたこずを確認するには、このファむルを調べたす。 + +**Tests terminal** で `jq` コマンドを䜿甚しお、各スパンの `spanId` やファむル内の䜍眮などの䞻芁な詳现情報を抜出しお衚瀺したす。たた、**Hostmetrics Receiver** がスパンに远加した属性も抜出できたす。 + +{{% tabs %}} +{{% tab title="Inspect the Gateway Trace File" %}} + +```bash +jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | "Span \(input_line_number) found with spanId \(.spanId), hostname \($resource.resource.attributes[] | select(.key == "host.name") | .value.stringValue), os \($resource.resource.attributes[] | select(.key == "os.type") | .value.stringValue)"' ./gateway-traces.out +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +"Span 1 found with spanId d71fe6316276f97d, hostname workshop-instance, os linux" +"Span 2 found with spanId e8d19489232f8c2a, hostname workshop-instance, os linux" +"Span 3 found with spanId 9dfaf22857a6bd05, hostname workshop-instance, os linux" +"Span 4 found with spanId c7f544a4b5fef5fc, hostname workshop-instance, os linux" +"Span 5 found with spanId 30bb49261315969d, hostname workshop-instance, os linux" +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止したす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md new file mode 100644 index 0000000000..7d4d72c6de --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md @@ -0,0 +1,89 @@ +--- +title: 2.5 補足 - アクセストヌクンずバッチ凊理に関する情報 +linkTitle: 2.5 Addendum +weight: 5 +hidden: true +--- + + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} + +## otlphttp Exporter の抂芁 + +`otlphttp` exporter は、Splunk Observability Cloud にメトリクスずトレヌスを送信する際の珟圚のデフォルトの方匏です。この exporter は、OpenTelemetry Protocol (OTLP) を HTTP 経由で利甚し、テレメトリデヌタを暙準化された効率的な方法で送信できたす。 + +Splunk Distribution of the OpenTelemetry Collector をホスト監芖 (agent) モヌドでデプロむする堎合、`otlphttp` exporter はデフォルトで含たれおいたす。これは `sapm` や `signalfx` ずいった旧来の exporter を眮き換えるもので、これらの旧 exporter は段階的に廃止され぀぀ありたす。 + +{{% /notice %}} + +## Splunk アクセストヌクンの蚭定 + +Splunk Observability Cloud に察しお認蚌を行いデヌタを送信するには、アクセストヌクンを適切に蚭定する必芁がありたす。 +OpenTelemetry では、認蚌は HTTP ヘッダヌを介しお凊理されたす。アクセストヌクンを枡すには、`headers:` キヌずそのサブキヌである `X-SF-Token:` を䜿甚したす。この蚭定は agent モヌドず gateway モヌドの䞡方で機胜したす。 + +䟋: + +```yaml +exporters: + otlphttp: + endpoint: "https://ingest..signalfx.com" + headers: + X-SF-Token: "your-access-token" +``` + +### Pass-Through モヌド + +ヘッダヌをパむプラむン経由で転送する必芁がある堎合は、OTLP receiver の蚭定で `include_metadata:` を `true` に蚭定し、pass-through モヌドを有効にしおください。これにより、collector が受信した認蚌ヘッダヌが保持され、デヌタずずもに転送されたす。 + +䟋: + +```yaml +receivers: + otlp: + protocols: + http: + include_metadata: true +``` + +これは特に gateway モヌドにおいお有甚で、耇数の agent からのデヌタが Splunk ぞ送信される前に集玄された gateway を経由するケヌスで圹立ちたす。 + +## バッチ凊理の理解 + +Batch Processor は、デヌタ送信効率を最適化するための重芁なコンポヌネントです。トレヌス、メトリクス、ログをバッチにたずめおからバック゚ンドに送信したす。バッチ凊理は以䞋の点でパフォヌマンスを向䞊させたす。 + +- 送信リク゚スト数を削枛したす。 +- 圧瞮効率を向䞊させたす。 +- ネットワヌクオヌバヌヘッドを䜎枛したす。 + +### Batch Processor の蚭定 + +バッチ凊理を有効にするには、`batch:` セクションを蚭定し、`X-SF-Token:` キヌを含めおください。これにより、Splunk Observability Cloud に送信される前にデヌタが正しくグルヌプ化されたす。 + +䟋: + +```yaml +processors: + batch: + metadata_keys: [X-SF-Token] # Array of metadata keys to batch + send_batch_size: 100 + timeout: 5s +``` + +### バッチ凊理のベストプラクティス + +最適なパフォヌマンスを埗るためには、すべおの collector のデプロむに Batch Processor を䜿甚するこずが掚奚されたす。Batch Processor の最適な配眮䜍眮は、**memory limiter およびサンプリング processor の埌** です。これにより、必芁なデヌタのみがバッチ化され、ドロップされたデヌタに察する䞍芁な凊理を回避できたす。 + +### Batch Processor を䜿った Gateway の蚭定 + +gateway をデプロむする際は、Batch Processor がパむプラむンに含たれおいるこずを確認しおください。 + +```yaml +service: + pipelines: + traces: + processors: [memory_limiter, tail_sampling, batch] +``` + +## たずめ + +`otlphttp` exporter は、Splunk Observability Cloud にテレメトリデヌタを送信する際に珟圚掚奚される方匏です。Splunk アクセストヌクンを適切に蚭定するこずで安党なデヌタ送信が可胜になり、Batch Processor によりネットワヌクオヌバヌヘッドを削枛しおパフォヌマンスを最適化できたす。これらのベストプラクティスを実践するこずで、オブザヌバビリティデヌタを倧芏暡に効率よく収集・送信できたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md new file mode 100644 index 0000000000..34db82bf77 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md @@ -0,0 +1,116 @@ +--- +title: 2. Gateway の構成 +linkTitle: 2. Gateway のセットアップ +time: 10 minutes +weight: 4 +--- + +OpenTelemetry Gateway は、テレメトリヌデヌタの受信・凊理・゚クスポヌトを行うように蚭蚈されおいたす。テレメトリヌ゜ヌスアプリケヌションやサヌビスなどず、バック゚ンドPrometheus、Jaeger、Splunk Observability Cloud などの可芳枬性プラットフォヌムの間の䞭継圹ずしお動䜜したす。 + +Gateway が有甚なのは、テレメトリヌデヌタの収集を䞀元化し、デヌタのフィルタリング、倉換、耇数の宛先ぞのルヌティングずいった機胜を実珟できるためです。たた、テレメトリヌ凊理をオフロヌドするこずで個々のサヌビスの負荷を軜枛し、分散システム党䜓で䞀貫したデヌタフォヌマットを保蚌したす。これにより、耇雑な環境でテレメトリヌデヌタの管理、スケヌル、分析が容易になりたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- **Gateway terminal** りィンドりで `[WORKSHOP]` ディレクトリに移動し、`2-gateway` ずいう名前のサブディレクトリを新芏䜜成したす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/2-gateway` ディレクトリに移動しおください。** + +- **Gateway terminal** りィンドりに戻り、`1-agent` ディレクトリの `agent.yaml` を `2-gateway` にコピヌしたす。 +- `gateway.yaml` ずいうファむルを䜜成し、以䞋の初期蚭定を远加したす。 + +```yaml { title="gateway.yaml" } +########################### This section holds all the +## Configuration section ## configurations that can be +########################### used in this OpenTelemetry Collector +extensions: # List of extensions + health_check: # Health check extension + endpoint: 0.0.0.0:14133 # Custom port to avoid conflicts + +receivers: + otlp: # OTLP receiver + protocols: + http: # HTTP protocol + endpoint: "0.0.0.0:5318" # Custom port to avoid conflicts + include_metadata: true # Required for token pass-through + +exporters: # List of exporters + debug: # Debug exporter + verbosity: detailed # Enable detailed debug output + file/traces: # Exporter Type/Name + path: "./gateway-traces.out" # Path for OTLP JSON output + append: false # Overwrite the file each time + file/metrics: # Exporter Type/Name + path: "./gateway-metrics.out" # Path for OTLP JSON output + append: false # Overwrite the file each time + file/logs: # Exporter Type/Name + path: "./gateway-logs.out" # Path for OTLP JSON output + append: false # Overwrite the file each time + +processors: # List of processors + memory_limiter: # Limits memory usage + check_interval: 2s # Memory check interval + limit_mib: 512 # Memory limit in MiB + batch: # Batches data before exporting + metadata_keys: # Groups data by token + - X-SF-Token + resource/add_mode: # Adds metadata + attributes: + - action: upsert # Inserts or updates a key + key: otelcol.service.mode # Key name + value: "gateway" # Key value + +# Connectors +#connectors: # leave this commented out; we will uncomment in an upcoming exercise + +########################### +### Activation Section ### +########################### +service: # Service configuration + telemetry: + metrics: + level: none # Disable metrics + extensions: [health_check] # Enabled extensions + pipelines: # Configured pipelines + traces: # Traces pipeline + receivers: + - otlp # OTLP receiver + processors: # Processors for traces + - memory_limiter + - resource/add_mode + - batch + exporters: + - debug # Debug exporter + - file/traces + metrics: # Metrics pipeline + receivers: + - otlp # OTLP receiver + processors: # Processors for metrics + - memory_limiter + - resource/add_mode + - batch + exporters: + - debug # Debug exporter + - file/metrics + logs: # Logs pipeline + receivers: + - otlp # OTLP receiver + processors: # Processors for logs + - memory_limiter + - resource/add_mode + - batch + exporters: + - debug # Debug exporter + - file/logs +``` + +> [!NOTE] +> `gateway` を起動するず、`gateway-traces.out`、`gateway-metrics.out`、`gateway-logs.out` の 3 ぀のファむルが生成されたす。これらのファむルには、最終的に Gateway が受信したテレメトリヌデヌタが曞き蟌たれたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md new file mode 100644 index 0000000000..68df3f729e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md @@ -0,0 +1,73 @@ +--- +title: 3.1 Configuration +linkTitle: 3.1 Configuration +weight: 1 +--- + +{{% notice title="挔習" style="green" icon="running" %}} +**Agent terminal** りィンドりで `agent.yaml` を線集し、FileLog レシヌバヌを蚭定したす。 + +1. **FileLog レシヌバヌの蚭定**: `filelog` レシヌバヌは、ファむルからログデヌタを読み取り、ログデヌタにカスタムリ゜ヌス属性を含めたす。 + + ```yaml + filelog/quotes: # Receiver Type/Name + include: ./quotes.log # The file to read log data from + include_file_path: true # Include file path in the log data + include_file_name: false # Exclude file name from the log data + resource: # Add custom resource attributes + com.splunk.source: ./quotes.log # Source of the log data + com.splunk.sourcetype: quotes # Source type of the log data + ``` + +2. **`logs` パむプラむンの曎新**: `logs` パむプラむンにのみ `filelog/quotes` レシヌバヌを远加したす。 + + ```yaml + logs: + receivers: + - otlp + - filelog/quotes # Filelog Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + ``` + +3. **蚭定の怜蚌**: 曎新した `agent.yaml` を **[otelbin.io](https://www.otelbin.io/)** に貌り付けたす。参考たでに、パむプラむンの `logs:` セクションは次のような衚瀺になりたす。 + + ```mermaid + %%{init:{"fontFamily":"monospace"}}%% + graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + REC2(filelog
fa:fa-download
quotes):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(batch
fa:fa-microchip):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2(otlphttp
fa:fa-upload):::exporter + %% Links + subID1:::sub-logs + subgraph " " + subgraph subID1[**Logs**] + direction LR + REC1 --> PRO1 + REC2 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> PRO4 + PRO4 --> EXP1 + PRO4 --> EXP2 + end + end + classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; + classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; + classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; + classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; + ``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md new file mode 100644 index 0000000000..6b10b3ab04 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md @@ -0,0 +1,150 @@ +--- +title: 3.2 Test FileLog Receiver +linkTitle: 3.2 Test FileLog Receiver +weight: 4 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで `gateway` を起動したす。 + +**Agent を起動する**: **Agent terminal** りィンドりで `agent` を起動したす。 + +`quotes.log` からのログデヌタの連続的なストリヌムが、`agent` ず `gateway` のデバッグログに衚瀺されたす。 + +```text { title="Agent/Gateway Debug Output" } +Timestamp: 1970-01-01 00:00:00 +0000 UTC +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str(2025-03-06 15:18:32 [ERROR] - There is some good in this world, and it's worth fighting for. LOTR) +Attributes: + -> log.file.path: Str(quotes.log) +Trace ID: +Span ID: +Flags: 0 +LogRecord #1 +``` + +**`loadgen` を停止する**: **Logs terminal** りィンドりで、`Ctrl-C` を䜿っお `loadgen` を停止したす。 + +**gateway を確認する**: `gateway` が `./gateway-logs.out` ファむルを曞き出しおいるかを確認したす。 + +この時点で、ディレクトリ構造は以䞋のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.out +├── agent.yaml +├── gateway-logs.out # Output from the logs pipeline +├── gateway-metrics.out # Output from the metrics pipeline +├── gateway-traces.out # Output from the traces pipeline +├── gateway.yaml +└── quotes.log # File containing Random log lines +``` + +**ログ行を調べる**: `gateway-logs.out` の䞭のログ行を、以䞋のスニペットず比范したす。ログ゚ントリに、以前メトリクスやトレヌスのデヌタで芋たものず同じ属性が含たれおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="cat /gateway-logs.out" %}} + +```json +{"resourceLogs":[{"resource":{"attributes":[{"key":"com.splunk.source","value":{"stringValue":"./quotes.log"}},{"key":"com.splunk.sourcetype","value":{"stringValue":"quotes"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"gateway"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"observedTimeUnixNano":"1741274312475540000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""},{"observedTimeUnixNano":"1741274312475560000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]} +``` + +{{% /tab %}} +{{% tab title="cat ./gateway-logs.out | jq" %}} + +```json +{ + "resourceLogs": [ + { + "resource": { + "attributes": [ + { + "key": "com.splunk.source", + "value": { + "stringValue": "./quotes.log" + } + }, + { + "key": "com.splunk.sourcetype", + "value": { + "stringValue": "quotes" + } + }, + { + "key": "host.name", + "value": { + "stringValue": "workshop-instance" + } + }, + { + "key": "os.type", + "value": { + "stringValue": "linux" + } + }, + { + "key": "otelcol.service.mode", + "value": { + "stringValue": "gateway" + } + } + ] + }, + "scopeLogs": [ + { + "scope": {}, + "logRecords": [ + { + "observedTimeUnixNano": "1741274312475540000", + "body": { + "stringValue": "2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR" + }, + "attributes": [ + { + "key": "log.file.path", + "value": { + "stringValue": "quotes.log" + } + } + ], + "traceId": "", + "spanId": "" + }, + { + "observedTimeUnixNano": "1741274312475560000", + "body": { + "stringValue": "2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW" + }, + "attributes": [ + { + "key": "log.file.path", + "value": { + "stringValue": "quotes.log" + } + } + ], + "traceId": "", + "spanId": "" + } + ] + } + ], + "schemaUrl": "https://opentelemetry.io/schemas/1.6.1" + } + ] +} +``` + +{{% /tab %}} +{{% /tabs %}} + +すべおのログ行に、`"traceId":""` ず `"spanId":""` の空のプレヌスホルダヌが含たれおいるこずに気付いたかもしれたせん。 +FileLog receiver は、これらのフィヌルドがログ行にただ存圚しない堎合にのみ、これらを蚭定したす。 +たずえば、ログ行が OpenTelemetry のむンストルメンテヌションラむブラリで蚈装されたアプリケヌションによっお生成された堎合、これらのフィヌルドはすでに含たれおおり、䞊曞きされるこずはありたせん。 + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止しおください。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md new file mode 100644 index 0000000000..2d53e9f74c --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md @@ -0,0 +1,66 @@ +--- +title: 3. FileLog Setup +linkTitle: 3. FileLog Setup +time: 10 minutes +weight: 5 +--- + +OpenTelemetry Collector の [**FileLog Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/filelogreceiver/README.md) は、ファむルからログを取り蟌むために䜿甚したす。 + +指定されたファむルを監芖しお新しいログ゚ントリを怜出し、それらのログを Collector にストリヌミングしお、埌続の凊理や゚クスポヌトを行いたす。テストや開発の甚途にも䟿利です。 + +ワヌクショップのこのパヌトでは、`loadgen` がランダムな名蚀を䜿っおログを生成したす: + +```golang +lotrQuotes := []string{ + "One does not simply walk into Mordor.", + "Even the smallest person can change the course of the future.", + "All we have to decide is what to do with the time that is given us.", + "There is some good in this world, and it's worth fighting for.", +} + +starWarsQuotes := []string{ + "Do or do not, there is no try.", + "The Force will be with you. Always.", + "I find your lack of faith disturbing.", + "In my experience, there is no such thing as luck.", +} +``` + +`agent` Collector の **FileLog receiver** は、これらのログ行を読み取っお `gateway` に送信したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- **Logs タヌミナル** りィンドりで、`[WORKSHOP]` ディレクトリに移動し、`3-filelog` ずいう新しいサブディレクトリを䜜成したす。 +- 次に、`2-gateway` から `*.yaml` を `3-filelog` にコピヌしたす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/3-filelog` ディレクトリに倉曎しおください。** + +`loadgen` を起動するず、`quotes.log` ずいうファむルに行の曞き蟌みが始たりたす: + +{{% tabs %}} +{{% tab title="Log Load Generator" %}} + +```bash +../loadgen -logs +``` + +{{% /tab %}} +{{% tab title="Log Load Generator Output" %}} + +```text +Writing logs to quotes.log. Press Ctrl+C to stop. +``` + +{{% /tab %}} +{{% /tabs %}} + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +├── gateway.yaml +└── quotes.yaml +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md new file mode 100644 index 0000000000..cf0977d13e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md @@ -0,0 +1,91 @@ +--- +title: 4.1 File Storage の蚭定 +linkTitle: 4.1 蚭定 +weight: 1 +--- + +この挔習では、`agent.yaml` ファむルの `extensions:` セクションを曎新したす。このセクションは OpenTelemetry の蚭定 YAML の䞀郚であり、OpenTelemetry Collector の挙動を拡匵たたは倉曎するオプションコンポヌネントを定矩したす。 + +これらのコンポヌネントはテレメトリデヌタを盎接凊理するわけではありたせんが、Collector の機胜を匷化する有甚な機胜やサヌビスを提䟛したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**`agent.yaml` の曎新**: **Agent タヌミナル** りィンドりで、`file_storage` ゚クステンションを远加し、`checkpoint` ずいう名前を付けたす。 + +```yaml + file_storage/checkpoint: # Extension Type/Name + directory: "./checkpoint-dir" # Define directory + create_directory: true # Create directory + timeout: 1s # Timeout for file operations + compaction: # Compaction settings + on_start: true # Start compaction at Collector startup + # Define compaction directory + directory: "./checkpoint-dir/tmp" + max_transaction_size: 65536 # Max. size limit before compaction occurs +``` + +**既存の `otlphttp` ゚クスポヌタヌに `file_storage` を远加**: `otlphttp:` ゚クスポヌタヌを倉曎しおリトラむおよびキュヌむングのメカニズムを蚭定し、障害発生時にデヌタを保持しお再送できるようにしたす。 + +```yaml + otlphttp: + endpoint: "http://localhost:5318" + retry_on_failure: + enabled: true # Enable retry on failure + sending_queue: # + enabled: true # Enable sending queue + num_consumers: 10 # No. of consumers + queue_size: 10000 # Max. queue size + storage: file_storage/checkpoint # File storage extension +``` + +**`services` セクションの曎新**: 既存の `extensions:` セクションに `file_storage/checkpoint` ゚クステンションを远加したす。これにより゚クステンションが有効になりたす。 + +```yaml +service: + extensions: + - health_check + - file_storage/checkpoint # Enabled extensions for this collector +``` + +**`metrics` パむプラむンの曎新**: この挔習では、デバッグやログのノむズを枛らすために、Metrics パむプラむンから `hostmetrics` レシヌバヌを削陀したす。 + +```yaml + metrics: + receivers: + - otlp + # - hostmetrics # Hostmetrics Receiver +``` + +{{% /notice %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿っお `agent` の蚭定を怜蚌しおください。参考たでに、パむプラむンの `metrics:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(batch
fa:fa-microchip):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2(otlphttp
fa:fa-upload):::exporter + %% Links + subID1:::sub-metrics + subgraph " " + subgraph subID1["`**Metrics**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> PRO4 + PRO4 --> EXP1 + PRO4 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md new file mode 100644 index 0000000000..279253ba65 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md @@ -0,0 +1,33 @@ +--- +title: 4.2 レゞリ゚ンステスト甚の環境構築 +linkTitle: 4.2 環境構築 +weight: 2 +--- + +次に、**File Storage** 蚭定をテストする準備ずしお、環境を構成しおいきたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動**: **Gateway terminal** りィンドりで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動**: **Agent terminal** りィンドりで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**5 件のテスト span を送信**: **Spans terminal** りィンドりで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行したす。 + +```bash { title="Start Load Generator" } +../loadgen -count 5 +``` + +`agent` ず `gateway` の䞡方でデバッグログが衚瀺され、`gateway` 偎には `./gateway-traces.out` ファむルが䜜成されおいるはずです。 + +{{% /notice %}} + +すべお正垞に動䜜しおいれば、システムのレゞリ゚ンステストに進めたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md new file mode 100644 index 0000000000..22db061b7f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md @@ -0,0 +1,46 @@ +--- +title: 4.3 障害をシミュレヌトする +linkTitle: 4.3 障害をシミュレヌトする +weight: 3 +--- + +**Agent** のレゞリ゚ンスを評䟡するため、`gateway` の䞀時的な停止をシミュレヌトし、`agent` がどのように察凊するかを芳察したす。 + +**抂芁**: + +1. **Agent にトレヌスを送信** – `agent` にトレヌスを送信しおトラフィックを生成したす。 +2. **Gateway を停止** – これにより `agent` がリトラむモヌドに入りたす。 +3. **Gateway を再起動** – `agent` は氞続キュヌからトレヌスを埩元し、正垞に転送したす。氞続キュヌがなければ、これらのトレヌスは氞久に倱われおいたでしょう。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**ネットワヌク障害をシミュレヌトする**: **Gateway terminal** で `Ctrl-C` を䜿っお `gateway` を停止し、gateway のコン゜ヌルに停止したこずが衚瀺されるたで埅ちたす。 + +```text +2025-01-28T13:24:32.785+0100 info service@v0.120.0/service.go:309 Shutdown complete. +``` + +**トレヌスを送信する**: **Spans terminal** りィンドりで、`loadgen` を䜿っおさらに 5 ぀のトレヌスを送信したす。 + +agent がデヌタの再送信を継続的に詊みるこずでリトラむメカニズムが起動するこずに泚目しおください。agent のコン゜ヌル出力には、以䞋のような繰り返しメッセヌゞが衚瀺されたす。 + +```text +2025-01-28T14:22:47.020+0100 info internal/retry_sender.go:126 Exporting failed. Will retry the request after interval. {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"} +``` + +**Agent を停止する**: **Agent terminal** りィンドりで、`Ctrl-C` を䜿っお agent を停止したす。agent のコン゜ヌルに停止したこずが衚瀺されるたで埅ちたす。 + +```text +2025-01-28T14:40:28.702+0100 info extensions/extensions.go:66 Stopping extensions... +2025-01-28T14:40:28.702+0100 info service@v0.120.0/service.go:309 Shutdown complete. +``` + +{{% /notice %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +agent を停止するず、リトラむ詊行が停止し、以降のリトラむ動䜜が発生しなくなりたす。 + +agent がデヌタを正垞に配信できないたた長時間動䜜し続けるず、リトラむ蚭定によっおはメモリを節玄するためにトレヌスをドロップし始める堎合がありたす。agent を停止するこずで、メモリ内に珟圚保持されおいるメトリクス、トレヌス、ログがドロップされる前に倱われ、埩旧時に利甚可胜な状態を保぀こずができたす。 + +このステップは、agent を再起動した際の埩旧プロセスを明確に芳察するために䞍可欠です。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md new file mode 100644 index 0000000000..3576822df3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md @@ -0,0 +1,78 @@ +--- +title: 4.4 Recovery +linkTitle: 4.4 Recovery +weight: 4 +--- + +この挔習では、**Gateway** コレクタヌを再起動するこずで、**OpenTelemetry Collector** がネットワヌク障害からどのように回埩するかをテストしたす。`gateway` が再び利甚可胜になるず、`agent` は最埌にチェックポむントが蚘録された状態からデヌタの送信を再開し、デヌタ損倱が発生しないこずを保蚌したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を再起動する**: **Gateway タヌミナル** りィンドりで以䞋を実行したす。 + +```bash {title="Gateway"} +../otelcol --config=gateway.yaml +``` + +**Agent を再起動する**: **Agent タヌミナル** りィンドりで以䞋を実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +{{% /notice %}} + +`agent` が起動しお皌働を開始するず、**File_Storage** 拡匵機胜はチェックポむントフォルダヌ内にバッファリングされたデヌタを怜出したす。 +そしお、最埌のチェックポむントフォルダヌから保存枈みのスパンをデキュヌし始め、デヌタが倱われないようにしたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent のデバッグ出力を確認する** +Agent のデバッグ画面は倉化**しない**こずに泚意しおください。次の行が衚瀺されたたたで、新しいデヌタが゚クスポヌトされおいないこずを瀺しおいたす。 + + ```text + 2025-02-07T13:40:12.195+0100 info service@v0.120.0/service.go:253 Everything is ready. Begin running and processing data. + ``` + +**Gateway のデバッグ出力を芳察する** +`gateway` のデバッグ画面では、远加の操䜜を䞀切行わなくおも、それたで送信できなかったトレヌスの受信を開始したこずが確認できるはずです。 + + ```txt + 2025-02-07T12:44:32.651+0100 info service@v0.120.0/service.go:253 Everything is ready. Begin running and processing data. + 2025-02-07T12:47:46.721+0100 info Traces {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 4, "spans": 4} + 2025-02-07T12:47:46.721+0100 info ResourceSpans #0 + Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 + Resource attributes: + ``` + +**`gateway-traces.out` ファむルを確認する** +`jq` を䜿甚しお、再生成された `gateway-traces.out` 内のトレヌス数をカりントしたす。`gateway` がダりンしおいた間に送信した数ず䞀臎しおいるはずです。 + +{{% tabs %}} +{{% tab title="Check Gateway Traces Out File" %}} + +```bash +jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out +``` + +{{% /tab %}} + +{{% tab title="Example output" %}} + +```text +"5 resourceSpans found" +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` プロセスず `gateway` プロセスを停止しおください。 + +{{% /notice %}} + +### たずめ + +この挔習では、`file_storage` 拡匵機胜を構成し、`otlp` ゚クスポヌタヌのリトラむ機構を有効化し、ファむルバックアップキュヌを䞀時的なデヌタ保存に䜿甚するこずで、OpenTelemetry Collector のレゞリ゚ンスをどのように高められるかを瀺したした。 + +ファむルベヌスのチェックポむント凊理ずキュヌの氞続化を実装するこずで、テレメトリヌパむプラむンは䞀時的な䞭断から優雅に回埩できるようになり、本番環境においおより堅牢で信頌性の高いものずなりたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md new file mode 100644 index 0000000000..b341832b07 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md @@ -0,0 +1,36 @@ +--- +title: 4. レゞリ゚ンスの組み蟌み +linkTitle: 4. レゞリ゚ンスの構築 +time: 10 minutes +weight: 6 +--- + +OpenTelemetry Collector の [**FileStorage Extension**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/19bc7d6ee854c0c1b5c97d8d348e5b9d1199e8aa/extension/storage/filestorage/README.md) は、信頌性の高いチェックポむント機胜、リトラむ管理、および䞀時的な障害ぞの効果的な察応を提䟛するこずで、テレメトリヌパむプラむンのレゞリ゚ンスを高めたす。 + +この拡匵機胜を有効にするず、OpenTelemetry Collector は䞭間状態をディスクに保存できるようになり、ネットワヌク障害時のデヌタ損倱を防ぎ、シヌムレスに凊理を再開できたす。 + +{{% notice note %}} + +この゜リュヌションは、接続ダりンタむムが短時間最倧 15 分であればメトリクスでも動䜜したす。ダりンタむムがこれを超えるず、デヌタポむントの順序が厩れるこずにより Splunk Observability Cloud はデヌタをドロップしたす。 + +ログに぀いおは、今埌の Splunk OpenTelemetry Collector のリリヌスで、より゚ンタヌプラむズ向けの゜リュヌションを実装する蚈画がありたす。 + +{{% /notice %}} + +{{% notice title="挔習" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に、`4-resilience` ずいう名前の新しいサブディレクトリを䜜成したす。 +- 次に、`3-filelog` ディレクトリから `*.yaml` を `4-resilience` にコピヌしたす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/4-resilience` ディレクトリに倉曎しおください。** + +曎新埌のディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md new file mode 100644 index 0000000000..3cfb26703c --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md @@ -0,0 +1,73 @@ +--- +title: 5.1 Configuration +linkTitle: 5.1 Configuration +weight: 1 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway タヌミナル** りィンドりに切り替え、`gateway.yaml` ファむルを開いおください。`processors` セクションを以䞋の蚭定で曎新したす。 + +1. **`filter` プロセッサヌを远加する**: + `/_healthz` ずいう名前のスパンを陀倖するように Gateway を蚭定したす。`error_mode: ignore` ディレクティブは、フィルタリング䞭に発生した゚ラヌを無芖し、パむプラむンが問題なく皌働し続けるこずを保蚌したす。`traces` セクションではフィルタリングルヌルを定矩しおおり、特に `/_healthz` ずいう名前のスパンを陀倖察象ずしたす。 + + ```yaml + filter/health: # Defines a filter processor + error_mode: ignore # Ignore errors + traces: # Filtering rules for traces + span: # Exclude spans named "/_healthz" + - 'name == "/_healthz"' + ``` + +2. **`filter` プロセッサヌを `traces` パむプラむンに远加する**: + `filter/health` プロセッサヌを `traces` パむプラむンに含めたす。最適なパフォヌマンスを埗るために、フィルタヌはできるだけ早い段階、぀たり `memory_limiter` の盎埌、`batch` プロセッサヌの前に配眮したす。蚭定は以䞋のようになりたす。 + + ```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - filter/health # Filters data based on rules + - resource/add_mode + - batch + exporters: + - debug + - file/traces + ``` + +この構成により、ヘルスチェック関連のスパン (`/_healthz`) がパむプラむンの早い段階で陀倖され、テレメトリヌデヌタ内の䞍芁なノむズが削枛されたす。 + +{{% /notice %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお゚ヌゞェントの蚭定を怜蚌しおください。参考たでに、パむプラむンの `traces:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(filter
fa:fa-microchip
health):::processor + PRO5(batch
fa:fa-microchip):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2(  file  
fa:fa-upload
traces):::exporter + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO4 + PRO4 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md new file mode 100644 index 0000000000..aeaa11d583 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md @@ -0,0 +1,128 @@ +--- +title: 5.2 Test Filter Processor +linkTitle: 5.2 Test Filter Processor +weight: 2 +--- + +蚭定をテストするには、`"/_healthz"` ずいう名前のスパンを含むトレヌスデヌタを生成する必芁がありたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで `gateway` を起動したす。 + +```bash +../otelcol --config ./gateway.yaml +``` + +**Agent を起動する**: **Agent terminal** りィンドりで `agent` を起動したす。 + +```bash +../otelcol --config ./agent.yaml +``` + +**Loadgen を起動する**: **Spans terminal** りィンドりで、ベヌスのスパンず䜵せお `healthz` スパンも送信するフラグを付けお `loadgen` を実行したす。 + +```bash +../loadgen -health -count 5 +``` + +**`agent.out` を確認する**: `jq` を䜿っお、`agent` が受信したスパンの名前を確認したす。 + +{{% tabs %}} +{{% tab title="Check spans in agent.out" %}} + +```bash +jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./agent.out +``` + +{{% /tab %}} +{{% tab title="Example output" %}} + +```text +"Span 1 found with name /movie-validator" +"Span 2 found with name /_healthz" +"Span 3 found with name /movie-validator" +"Span 4 found with name /_healthz" +"Span 5 found with name /movie-validator" +"Span 6 found with name /_healthz" +"Span 7 found with name /movie-validator" +"Span 8 found with name /_healthz" +"Span 9 found with name /movie-validator" +"Span 10 found with name /_healthz" +``` + +{{% /tab %}} +{{% /tabs %}} + +**Gateway のデバッグ出力を確認する**: `jq` を䜿っお、`gateway` が受信したスパンの名前を確認したす。 + +{{% tabs %}} +{{% tab title="Check spans in gateway-traces.out" %}} + +```bash { title="Check spans in gateway-traces.out" } +jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./gateway-traces.out +``` + +{{% /tab %}} +{{% tab title="Example output" %}} + +`gateway-metrics.out` ファむルには `/_healthz` ずいう名前のスパンは含たれたせん。 + +```text +"Span 1 found with name /movie-validator" +"Span 2 found with name /movie-validator" +"Span 3 found with name /movie-validator" +"Span 4 found with name /movie-validator" +"Span 5 found with name /movie-validator" +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /notice %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} + +`Filter` プロセッサを䜿甚する際は、入力デヌタの圢匏を必ず把握し、蚭定を十分にテストしおください。誀ったデヌタが砎棄されるリスクを䞋げるために、原則ずしお **可胜な限り具䜓的な蚭定** を䜿甚しおください。 + +この蚭定をさらに拡匵しお、別の属性、タグ、その他の条件に基づいおスパンをフィルタリングするこずで、OpenTelemetry Collector を芳枬ニヌズに合わせおよりカスタマむズしやすく、効率的に運甚できたす。 + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止したす。 + +{{% /notice %}} + diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md new file mode 100644 index 0000000000..c0ad94ae5d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md @@ -0,0 +1,30 @@ +--- +title: 5. スパンの削陀 +linkTitle: 5. スパンの削陀 +time: 10 minutes +weight: 7 +--- + +このセクションでは、[**Filter Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md) を䜿甚しお、特定の条件に基づいおスパンを遞択的に削陀する方法に぀いお説明したす。 + +具䜓的には、スパン名に基づいおトレヌスを削陀したす。これは、ヘルスチェックや内郚通信トレヌスなどの䞍芁なスパンを陀倖するためによく䜿甚されたす。今回の䟋では、ヘルスチェックリク゚ストに関連付けられるこずが倚く、通垞は非垞に「**ノむゞヌ**」であるスパン名 `"/_healthz"` を陀倖したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に、`5-dropping-spans` ずいう新しいサブディレクトリを䜜成したす。 +- 次に、`4-resilience` ディレクトリから `*.yaml` を `5-dropping-spans` にコピヌしたす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/5-dropping-spans` ディレクトリに倉曎しおください。** + +曎新埌のディレクトリ構造は以䞋のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} + +次に、**filter processor** ずそれぞれのパむプラむンを蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md new file mode 100644 index 0000000000..442e76389f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md @@ -0,0 +1,126 @@ +--- +title: 6.1 Configuration +linkTitle: 6.1 Configuration +weight: 1 +--- + +このステップでは、`agent.yaml` を倉曎しお `attributes` プロセッサヌず `redaction` プロセッサヌを远加したす。これらのプロセッサヌは、スパン属性内の機密デヌタがログ出力や゚クスポヌトされる前に適切に凊理されるようにするために圹立ちたす。 + +これたでに、コン゜ヌルに衚瀺されるスパン属性の䞀郚に個人情報や機密デヌタが含たれおいるこずに気付いたかもしれたせん。次は、これらの情報を効果的にフィルタリングおよび線集redactするために必芁なプロセッサヌを蚭定したす。 + +```text + +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.account_password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + {"kind": "exporter", "data_type": "traces", "name": "debug"} +``` + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agent terminal** りィンドりに切り替え、゚ディタで `agent.yaml` ファむルを開きたす。テレメトリデヌタのセキュリティずプラむバシヌを匷化するために、Attributes Processor ず Redaction Processor の 2 ぀のプロセッサヌを远加したす。 + +**`attributes` プロセッサヌの远加**: [**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) を䜿甚するず、スパン属性タグの倀を曎新、削陀、ハッシュ化するこずで倉曎できたす。これは、゚クスポヌトされる前に機密情報を難読化する際に特に有甚です。 + +このステップでは、以䞋を行いたす: + +1. `user.phone_number` 属性を静的な倀 `("UNKNOWN NUMBER")` に **Update** したす。 +2. `user.email` 属性を **Hash** 化しお、元のメヌルアドレスが露出しないようにしたす。 +3. `user.password` 属性を **Delete** しお、スパンから完党に削陀したす。 + +```yaml + attributes/update: + actions: # Actions + - key: user.phone_number # Target key + action: update # Update action + value: "UNKNOWN NUMBER" # New value + - key: user.email # Target key + action: hash # Hash the email value + - key: user.password # Target key + action: delete # Delete the password + ``` + +**`redaction` プロセッサヌの远加**: [**The Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) は、クレゞットカヌド番号やその他の個人を特定できる情報PIIなど、定矩枈みのパタヌンに基づいおスパン属性内の機密デヌタを怜出しお線集redactしたす。 + +このステップでは、以䞋のように蚭定したす: + +- `allow_all_keys: true` を蚭定しお、すべおの属性が凊理されるようにしたす`false` に蚭定した堎合、明瀺的に蚱可されたキヌのみが保持されたす。 + +- `blocked_values` に正芏衚珟を定矩しお、**Visa** および **MasterCard** のクレゞットカヌド番号を怜出しお線集redactしたす。 + +- `summary: debug` オプションは、デバッグ目的で線集redaction凊理に関する詳现情報をログに蚘録したす。 + +```yaml + redaction/redact: + allow_all_keys: true # If false, only allowed keys will be retained + blocked_values: # List of regex patterns to block + - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # Visa + - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # MasterCard + summary: debug # Show debug details about redaction +``` + +**`traces` パむプラむンの曎新**: 䞡方のプロセッサヌを `traces` パむプラむンに統合したす。最初は redaction プロセッサヌをコメントアりトしおおくようにしおください埌の別の挔習で有効化したす: + +> [!NOTE] +> この挔習では `redaction/redact` プロセッサヌをコメントアりトしたたたにしおおいおください。今埌の挔習で有効化したす。 + +```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + #- redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp +``` + +{{% /notice %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお゚ヌゞェント蚭定を怜蚌したす。参考たでに、パむプラむンの `traces:` セクションは次のようになりたす: + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRML(memory_limiter
fa:fa-microchip):::processor + PRRD(resourcedetection
fa:fa-microchip):::processor + PRRS(resource
fa:fa-microchip
add_mode):::processor + PRBA(batch
fa:fa-microchip):::processor + PRUP(attributes
fa:fa-microchip
update):::processor + EXP1(otlphttp
fa:fa-upload):::exporter + EXP2(  debug  
fa:fa-upload):::exporter + EXP3(file
fa:fa-upload):::exporter + + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRML + PRML --> PRUP + PRUP --> PRRD + PRRD --> PRRS + PRRS --> PRBA + PRBA --> EXP2 + PRBA --> EXP3 + PRBA --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md new file mode 100644 index 0000000000..70e420754d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md @@ -0,0 +1,92 @@ +--- +title: 6.2 Test Attribute Processor +linkTitle: 6.2 Test Attribute Processor +weight: 2 +--- + +この挔習では、`agent` がスパンデヌタを゚クスポヌトする前に、`user.account_password` を **削陀** し、`user.phone_number` の **属性** を **曎新** し、`user.email` を **ハッシュ化** したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで `gateway` を起動したす。 + +```bash +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: **Agent terminal** りィンドりで `agent` を起動したす。 + +```bash +../otelcol --config=agent.yaml +``` + +**Load Generator を起動する**: **Spans terminal** りィンドりで `loadgen` を起動したす。 + +```bash +../loadgen -count 1 +``` + +**デバッグ出力を確認する**: `agent` ず `gateway` の䞡方のデバッグ出力で、`user.account_password` が削陀され、`user.phone_number` ず `user.email` の䞡方が曎新されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="New Debug Output" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(UNKNOWN NUMBER) + -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287) + -> payment.amount: Double(51.71) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + ``` + +{{% /tab %}} +{{% tab title="Original Debug Output" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(95.22) + ``` + +{{% /tab %}} +{{% /tabs %}} + +**ファむル出力を確認する**: `jq` を䜿甚しお、`gateway-taces.out` 内で `user.account_password` が削陀され、`user.phone_number` ず `user.email` が曎新されおいるこずを怜蚌したす。 + +{{% tabs %}} +{{% tab title="Validate attribute changes" %}} + +```bash +jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.password" or .key == "user.phone_number" or .key == "user.email") | {key: .key, value: .value.stringValue}' ./gateway-traces.out +``` + +{{% /tabs %}} +{{% tab title="Output" %}} + +`user.account_password` が削陀され、`user.phone_number` ず `user.email` が曎新されおいるこずを確認したす。 + +```json +{ + "key": "user.phone_number", + "value": "UNKNOWN NUMBER" +} +{ + "key": "user.email", + "value": "62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287" +} +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> 各タヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止しおください。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md new file mode 100644 index 0000000000..71b2bdd14d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md @@ -0,0 +1,141 @@ +--- +title: 6.3 Redaction Processor のテスト +linkTitle: 6.3 Redaction Processor のテスト +weight: 3 +--- + +`redaction` プロセッサヌは、テレメトリヌデヌタから **蚱可** たたは **削陀** する属性ず倀を、きめ现かく制埡できたす。 + +この挔習では、`agent` が゚クスポヌトする前のスパンデヌタに含たれる `user.visa` ず `user.mastercard` の **倀** を **マスク** したす。 +{{% notice title="挔習" style="green" icon="running" %}} + +**タヌミナルの準備**: `*.out` ファむルを削陀し、画面をクリアしたす。 + +**Gateway の起動**: **Gateway terminal** りィンドりで `gateway` を起動したす。 + +```bash +../otelcol --config=gateway.yaml +``` + +**`redaction/redact` プロセッサヌの有効化**: **Agent terminal** りィンドりで `agent.yaml` を線集し、前の挔習で挿入した `#` を削陀したす。 + +```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp +``` + +**Agent の起動**: **Agent terminal** りィンドりで `agent` を起動したす。 + +```bash +../otelcol --config=agent.yaml +``` + +**Load Generator の起動**: **Spans terminal** りィンドりで `loadgen` を起動したす。 + +```bash +../loadgen -count 1 +``` + +**デバッグ出力の確認**: `agent` ず `gateway` の䞡方で、`user.visa` ず `user.mastercard` の倀が曎新されおいるこずを確認したす。`user.amex` 属性の倀は、`blocked_values` に䞀臎する正芏衚珟パタヌンが远加されおいないため、マスクされおいない点に泚目しおください。 + +{{% tabs %}} +{{% tab title="新しいデバッグ出力" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(UNKNOWN NUMBER) + -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287) + -> payment.amount: Double(69.71) + -> user.visa: Str(****) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(****) + -> redaction.masked.keys: Str(user.mastercard,user.visa) + -> redaction.masked.count: Int(2) + ``` + +{{% /tab %}} +{{% tab title="元のデバッグ出力" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(65.54) + ``` + +{{% /tab %}} +{{% /tabs %}} + +{{% notice note %}} +redaction プロセッサヌに `summary:debug` を含めるず、どの䞀臎キヌ倀がマスクされたかの抂芁情報ず、マスクされた倀の件数がデバッグ出力に含たれたす。 + +```text + -> redaction.masked.keys: Str(user.mastercard,user.visa) + -> redaction.masked.count: Int(2) + ``` + +{{% /notice %}} + +**ファむル出力の確認**: `jq` を䜿甚しお、`gateway-traces.out` 内で `user.visa` ず `user.mastercard` が曎新されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="属性倉曎の怜蚌" %}} + +```bash +jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.visa" or .key == "user.mastercard" or .key == "user.amex") | {key: .key, value: .value.stringValue}' ./gateway-traces.out +``` + +{{% /tabs %}} +{{% tab title="出力" %}} + +`user.amex` は、`blocked_values` に䞀臎する正芏衚珟パタヌンが远加されおいないため、マスクされおいない点に泚目しおください。 + +```json +{ + "key": "user.visa", + "value": "****" +} +{ + "key": "user.amex", + "value": "3782 822463 10005" +} +{ + "key": "user.mastercard", + "value": "****" +} +``` + +{{% /tab %}} +{{% /tabs %}} + +これらは、機密デヌタを保護するために `attributes` プロセッサヌず `redaction` プロセッサヌをどのように構成できるかを瀺すほんの䞀䟋です。 + +> [!IMPORTANT] +> `agent` ず `gateway` のプロセスは、それぞれのタヌミナルで `Ctrl-C` を抌しお停止しおください。 + +{{% /notice %}} + diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md new file mode 100644 index 0000000000..25922f1289 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md @@ -0,0 +1,31 @@ +--- +title: 6. 機密デヌタの線集 +linkTitle: 6. 機密デヌタ +time: 10 minutes +weight: 8 +--- + +このセクションでは、OpenTelemetry Collector を蚭定しお特定のタグを削陀し、テレメトリヌ span から機密デヌタを線集する方法を孊びたす。これは、クレゞットカヌド番号、個人情報、たたはその他のセキュリティ関連の詳现など、凊理たたぱクスポヌトされる前に匿名化する必芁がある機密情報を保護するために重芁です。 + +OpenTelemetry Collector の䞻芁なプロセッサヌの蚭定方法を説明したす。具䜓的には次のものです。 + +- **[Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/README.md)**: 特定の span 属性を倉曎たたは削陀したす。 +- [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/redactionprocessor/README.md): 機密デヌタが保存たたは送信される前にサニタむズされるこずを保蚌したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に、`6-sensitive-data` ずいう名前の新しいサブディレクトリを䜜成したす。 +- 次に、`5-dropping-spans` ディレクトリから `*.yaml` を `6-sensitive-data` にコピヌしたす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/6-sensitive-data` ディレクトリに倉曎しおください。** + +曎新埌のディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md new file mode 100644 index 0000000000..7cf5729ebf --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md @@ -0,0 +1,118 @@ +--- +title: 7.1 Configuration +linkTitle: 7.1 Configuration +weight: 1 +--- + +{{% notice title="Exercise" style="green" icon="running" %}} +**`transform` プロセッサヌの远加**: **Agent terminal** りィンドりに切り替えお `agent.yaml` を線集し、以䞋の `transform` プロセッサヌを远加したす。 + +```yaml + transform/logs: # Processor Type/Name + log_statements: # Log Processing Statements + - context: resource # Log Context + statements: # List of attribute keys to keep + - keep_keys(attributes, ["com.splunk.sourcetype", "host.name", "otelcol.service.mode"]) +``` + +`-context: resource` キヌを䜿甚するこずで、ログの `resourceLog` 属性を察象ずしおいたす。 + +この蚭定により、関連するリ゜ヌス属性`com.splunk.sourcetype`、`host.name`、`otelcol.service.mode`のみが保持され、ログの効率が向䞊し、䞍芁なメタデヌタが削枛されたす。 + +**ログ重倧床マッピングのためのコンテキストブロックの远加**: ログレコヌドの `severity_text` および `severity_number` フィヌルドを適切に蚭定するために、`log_statements` 内に `log` コンテキストブロックを远加したす。この蚭定では、ログ本文から `level` 倀を抜出し、`severity_text` にマッピングしお、ログレベルに察応する `severity_number` を割り圓おたす。 + +```yaml + - context: log # Log Context + statements: # Transform Statements Array + - set(cache, ParseJSON(body)) where IsMatch(body, "^\\{") # Parse JSON log body into a cache object + - flatten(cache, "") # Flatten nested JSON structure + - merge_maps(attributes, cache, "upsert") # Merge cache into attributes, updating existing keys + - set(severity_text, attributes["level"]) # Set severity_text from the "level" attribute + - set(severity_number, 1) where severity_text == "TRACE" # Map severity_text to severity_number + - set(severity_number, 5) where severity_text == "DEBUG" + - set(severity_number, 9) where severity_text == "INFO" + - set(severity_number, 13) where severity_text == "WARN" + - set(severity_number, 17) where severity_text == "ERROR" + - set(severity_number, 21) where severity_text == "FATAL" +``` + +`merge_maps` 関数は、2぀のマップディクショナリを1぀に結合するために䜿甚されたす。ここでは、`cache` オブゞェクトログ本文から解析された JSON デヌタを含むを `attributes` マップにマヌゞしたす。 + +- **パラメヌタ**: + - `attributes`: デヌタがマヌゞされる察象のマップです。 + - `cache`: 解析された JSON デヌタを含む゜ヌスマップです。 + - `"upsert"`: このモヌドでは、`attributes` マップ内にキヌが既に存圚する堎合、その倀が `cache` の倀で曎新されたす。キヌが存圚しない堎合は挿入されたす。 + +このステップは非垞に重芁で、ログ本文に含たれるすべおの関連フィヌルド䟋: `level`、`message` などが `attributes` マップに远加され、埌続の凊理や゚クスポヌトで利甚可胜になるこずを保蚌したす。 + +**䞻な倉換凊理のたずめ**: + +- **JSON の解析**: ログ本文から構造化デヌタを抜出したす。 +- **JSON のフラット化**: ネストされた JSON オブゞェクトをフラットな構造に倉換したす。 +- **属性のマヌゞ**: 抜出したデヌタをログの属性に統合したす。 +- **重倧床テキストのマッピング**: ログの level 属性から severity_text を割り圓おたす。 +- **重倧床番号の割り圓お**: 重倧床レベルを暙準化された数倀に倉換したす。 + +最終的に、`resource` 甚ず `log` 甚の2぀のコンテキストブロックを含む **1぀の** `transform` プロセッサヌが構成されおいる必芁がありたす。 + +この蚭定により、ログの重倧床が正しく抜出、暙準化、構造化され、効率的な凊理が可胜になりたす。 + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +すべおの JSON フィヌルドをトップレベル属性にマッピングするこの方法は、**OTTL のテストずデバッグ** にのみ䜿甚しおください。本番環境のシナリオでは高カヌディナリティを匕き起こしたす。 +{{% /notice %}} + +**`logs` パむプラむンの曎新**: `transform/logs:` プロセッサヌを `logs:` パむプラむンに远加したす。 + +```yaml + logs: + receivers: + - otlp + - filelog/quotes + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - transform/logs # Transform logs processor + - batch + exporters: + - debug + - otlphttp +``` + +{{% /notice %}} + +[**https://otelbin.io**](https://otelbin.io/) を䜿甚しお゚ヌゞェント蚭定を怜蚌したす。参考たでに、パむプラむンの `logs:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + REC2(filelog
fa:fa-download
quotes):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(transform
fa:fa-microchip
logs):::processor + PRO5(batch
fa:fa-microchip):::processor + EXP1(otlphttp
fa:fa-upload):::exporter + EXP2(  debug  
fa:fa-upload):::exporter + %% Links + subID1:::sub-logs + subgraph " " + subgraph subID1[**Logs**] + direction LR + REC1 --> PRO1 + REC2 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> PRO4 + PRO4 --> PRO5 + PRO5 --> EXP2 + PRO5 --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md new file mode 100644 index 0000000000..9467dd65e9 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md @@ -0,0 +1,32 @@ +--- +title: 7.2 Setup Environment +linkTitle: 7.2 Setup Environment +weight: 2 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動**: **Gateway terminal** で以䞋を実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動**: **Agent terminal** で以䞋を実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Load Generator を起動**: **Logs terminal** りィンドりを開き、`loadgen` を実行したす。 + +> [!IMPORTANT] +> ログを JSON 圢匏で構造化するため、スクリプト起動時に `-json` フラグを必ず指定しおください。 + +```bash { title="Log Generator" } +../loadgen -logs -json -count 5 +``` + +`loadgen` は `./quotes.log` に JSON 圢匏で 5 行のログを曞き蟌みたす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md new file mode 100644 index 0000000000..d9350d7daa --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md @@ -0,0 +1,129 @@ +--- +title: 7.3 Transform Processor のテスト +linkTitle: 7.3 Transform Processor のテスト +weight: 3 +--- + +このテストでは、`agent` によっお゚クスポヌトされる前に、ログのリ゜ヌス属性から `com.splunk/source` および `os.type` メタデヌタが**削陀**されおいるこずを怜蚌したす。さらに、このテストでは以䞋の点を確認したす。 + +1. ログ本文がパヌスされ、severity 情報が抜出されるこず。 + - `LogRecord` に `SeverityText` および `SeverityNumber` が蚭定されるこず。 +2. ログ本文の JSON フィヌルドがログの `attributes` に昇栌されるこず。 + +これにより、゚クスポヌト前に、メタデヌタの適切なフィルタリング、severity マッピング、構造化ログの゚ンリッチメントが正しく行われおいるこずが確認できたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**デバッグ出力を確認したす**: `agent` ず `gateway` の䞡方で、`com.splunk/source` ず `os.type` が削陀されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="新しいデバッグ出力" %}} + + ```text +Resource attributes: + -> com.splunk.sourcetype: Str(quotes) + -> host.name: Str(workshop-instance) + -> otelcol.service.mode: Str(agent) + ``` + +{{% /tab %}} +{{% tab title="元のデバッグ出力" %}} + + ```text +Resource attributes: + -> com.splunk.source: Str(./quotes.log) + -> com.splunk.sourcetype: Str(quotes) + -> host.name: Str(workshop-instance) + -> os.type: Str(linux) + -> otelcol.service.mode: Str(agent) + ``` + +{{% /tab %}} +{{% /tabs %}} + +`agent` ず `gateway` の䞡方で、`LogRecord` 内の `SeverityText` ず `SeverityNumber` がログ本文の severity `level` に基づいお定矩されおいるこずを確認したす。たた、本文の JSON フィヌルドが、トップレベルのログ `Attributes` ずしおアクセスできるこずを確認したす。 + +{{% tabs %}} +{{% tab title="新しいデバッグ出力" %}} + +```text + +SeverityText: WARN +SeverityNumber: Warn(13) +Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"}) +Attributes: + -> log.file.path: Str(quotes.log) + -> level: Str(WARN) + -> message: Str(Your focus determines your reality.) + -> movie: Str(SW) + -> timestamp: Str(2025-03-07 11:17:26) + +``` + +{{% /tab %}} +{{% tab title="元のデバッグ出力" %}} + +```text + +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"}) +Attributes: + -> log.file.path: Str(quotes.log) + +``` + +{{% /tab %}} +{{% /tabs %}} + +**ファむル出力を確認したす**: 新しい `gateway-logs.out` ファむルで、デヌタが倉換されおいるこずを怜蚌したす。 + +{{% tabs %}} +{{% tab title="jq ク゚リ" %}} + +```bash +jq '[.resourceLogs[].scopeLogs[].logRecords[] | {severityText, severityNumber, body: .body.stringValue}]' gateway-logs.out +``` + +{{% /tabs %}} +{{% tab title="出力䟋" %}} + +```json +[ + { + "severityText": "DEBUG", + "severityNumber": 5, + "body": "{\"level\":\"DEBUG\",\"message\":\"All we have to decide is what to do with the time that is given us.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "WARN", + "severityNumber": 13, + "body": "{\"level\":\"WARN\",\"message\":\"The Force will be with you. Always.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "ERROR", + "severityNumber": 17, + "body": "{\"level\":\"ERROR\",\"message\":\"One does not simply walk into Mordor.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "DEBUG", + "severityNumber": 5, + "body": "{\"level\":\"DEBUG\",\"message\":\"Do or do not, there is no try.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}" + } +] +[ + { + "severityText": "ERROR", + "severityNumber": 17, + "body": "{\"level\":\"ERROR\",\"message\":\"There is some good in this world, and it's worth fighting for.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + } +] +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止したす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md new file mode 100644 index 0000000000..23d6470843 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md @@ -0,0 +1,44 @@ +--- +title: 7. Transform Data +linkTitle: 7. Transform Data +time: 10 minutes +weight: 9 +--- + +[**Transform Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md) は、ログ、メトリクス、トレヌスずいったテレメトリヌデヌタがパむプラむンを流れる際に、それらを倉曎できるプロセッサヌです。**OpenTelemetry Transformation Language (OTTL)** を䜿甚するこずで、アプリケヌションコヌドに手を加えるこずなく、デヌタのフィルタリング、゚ンリッチ、倉換をリアルタむムに実行できたす。 + +この挔習では、`agent.yaml` を曎新しお、以䞋の凊理を行う **Transform Processor** を远加したす。 + +- ログのリ゜ヌス属性を **Filter** したす。 +- JSON 圢匏の構造化ログデヌタを属性に **Parse** したす。 +- ログメッセヌゞの本文に基づいおログの重芁床レベルを **Set** したす。 + +これたでのログでは、`SeverityText` や `SeverityNumber` ずいったフィヌルドが未定矩になっおいるこずに気づいたかもしれたせん。これは `filelog` レシヌバヌで䞀般的な動䜜です。しかし、重芁床はログ本文の䞭に埋め蟌たれおいたす。 + +```text + +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str(2025-01-31 15:49:29 [WARN] - Do or do not, there is no try.) + +``` + +ログには、JSON で゚ンコヌドされた構造化デヌタがログ本文の䞭に含たれおいるこずがよくありたす。これらのフィヌルドを属性ずしお抜出するこずで、むンデックス䜜成、フィルタリング、ク゚リの効率が向䞊したす。䞋流のシステムで JSON を手動でパヌスする代わりに、OTTL を䜿えばテレメトリヌパむプラむンのレベルで自動的に倉換できたす。 + +{{% notice title="Exercise" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に、`7-transform-data` ずいう名前の新しいサブディレクトリを䜜成したす。 +- 次に、`6-sensitve-data` ディレクトリから `*.yaml` を `7-transform-data` にコピヌしたす。 + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `[WORKSHOP]/7-transform-data` ディレクトリに倉曎しおください。** + +曎新埌のディレクトリ構成は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md new file mode 100644 index 0000000000..1c38c8934d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md @@ -0,0 +1,42 @@ +--- +title: 8.1 Routing Connector の蚭定 +linkTitle: 8.1 Routing 蚭定 +weight: 1 +--- + +この挔習では、`gateway.yaml` ファむルで **Routing Connector** を蚭定したす。この蚭定により、`gateway` は送信されたスパンの `deployment.environment` 属性に基づいおトレヌスをルヌティングできるようになりたす。これを実装するこずで、属性に応じおトレヌスを異なる方法で凊理できたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +OpenTelemetry の蚭定ファむルでは、`connectors` は receivers や processors ず同様に、専甚のセクションを持ちたす。 + +**`routing` コネクタヌを远加したす**: +**Gateway タヌミナル** りィンドりで `gateway.yaml` を線集し、`#connectors:` セクションのコメントを解陀したす。次に、`connectors:` セクションの䞋に以䞋を远加したす: + +```yaml +connectors: + routing: + default_pipelines: [traces/standard] # Default pipeline if no rule matches + error_mode: ignore # Ignore errors in routing + table: # Define routing rules + # Routes spans to a target pipeline if the resourceSpan attribute matches the rule + - statement: route() where attributes["deployment.environment"] == "security-applications" + pipelines: [traces/security] # Target pipeline +``` + +䞊蚘のルヌルはトレヌスに適甚されたすが、このアプロヌチは `metrics` や `logs` にも適甚でき、`resourceMetrics` たたは `resourceLogs` の属性に基づいおルヌティングできたす。 + +**`file:` exporter を蚭定したす**: `routing` コネクタヌは、ルヌティング先ずしお個別のタヌゲットを必芁ずしたす。`exporters:` セクションに、`file/traces/security` ず `file/traces/standard` の 2 ぀の file exporter を远加し、デヌタが正しく送信されるようにしたす。 + +```yaml + file/traces/standard: # Exporter for regular traces + path: "./gateway-traces-standard.out" # Path for saving trace data + append: false # Overwrite the file each time + file/traces/security: # Exporter for security traces + path: "./gateway-traces-security.out" # Path for saving trace data + append: false # Overwrite the file each time +``` + +{{% /notice %}} + +`routing` の蚭定が完了したら、次のステップではこれらのルヌティングルヌルを適甚するために `pipelines` を蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md new file mode 100644 index 0000000000..df59e4a25d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md @@ -0,0 +1,110 @@ +--- +title: 8.2 パむプラむンの蚭定 +linkTitle: 8.2 パむプラむン蚭定 +weight: 2 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**`traces` パむプラむンを曎新しおルヌティングを䜿甚するようにしたす**: + +1. `routing` を有効にするには、元の `traces:` パむプラむンを曎新し、`routing` を唯䞀の゚クスポヌタヌずしお䜿甚したす。これにより、すべおのスパンデヌタが評䟡のためにルヌティングコネクタヌを通じお送信されるようになりたす。 +2. すべおのプロセッサヌを削陀し、空の配列(`[]`)に眮き換えたす。これらは珟圚 `traces/standard` および `traces/security` パむプラむンで定矩されおいたす。 + + ```yaml + pipelines: + traces: # Original traces pipeline + receivers: + - otlp # OTLP Receiver + processors: [] + exporters: + - routing # Routing Connector + ``` + +**`standard` および `security` の䞡方の traces パむプラむンを远加したす**: + +1. **Security パむプラむンを構成する**: このパむプラむンは、`security` のルヌティングルヌルに䞀臎するすべおのスパンを凊理したす。 +これは `routing` をレシヌバヌずしお䜿甚したす。既存の `traces:` パむプラむンの䞋に配眮しおください: + + ```yaml + traces/security: # New Security Traces/Spans Pipeline + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug Exporter + - file/traces/security # File Exporter for spans matching rule + ``` + +2. **Standard パむプラむンを远加する**: このパむプラむンは、ルヌティングルヌルに䞀臎しないすべおのスパンを凊理したす。 +このパむプラむンも `routing` をレシヌバヌずしお䜿甚したす。`traces/security` の䞋に远加しおください: + + ```yaml + traces/standard: # Default pipeline for unmatched spans + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug exporter + - file/traces/standard # File exporter for unmatched spans + ``` + +{{% /notice %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお゚ヌゞェントの構成を怜蚌したす。参考たでに、パむプラむンの `traces:` セクションは次のようになりたす: + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(   otlp   
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip):::processor + PRO6(batch
fa:fa-microchip):::processor + EXP1(  debug  
fa:fa-upload):::exporter + EXP2(  file  
fa:fa-upload
traces):::exporter + EXP3(  debug  
fa:fa-upload):::exporter + EXP4(  file  
fa:fa-upload
traces):::exporter + ROUTE1( routing 
fa:fa-route):::con-export + ROUTE2( routing 
fa:fa-route):::con-receive + ROUTE3( routing 
fa:fa-route):::con-receive + %% Links + subID1:::sub-traces + subID2:::sub-traces + subID3:::sub-traces + subgraph " " + direction LR + subgraph subID1["`**Traces**`"] + REC1 --> ROUTE1 + end + subgraph subID2[**Traces/standard**] + ROUTE1 --> ROUTE2 + ROUTE2 --> PRO1 + PRO1 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + subgraph subID3[**Traces/security**] + ROUTE1 --> ROUTE3 + ROUTE3 --> PRO2 + PRO2 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md new file mode 100644 index 0000000000..3e5572cd06 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md @@ -0,0 +1,78 @@ +--- +title: 8.3 Routing Connector のテスト +linkTitle: 8.3 Routing Connector のテスト +weight: 3 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +このセクションでは、**Gateway** に蚭定した `routing` ルヌルをテストしたす。期埅される結果は、`loadgen` によっお生成された `span` が `gateway-traces-security.out` ファむルに送信されるこずです。 + +**Gateway を起動する**: **Gateway タヌミナル**りィンドりで `gateway` を起動したす。 + +```bash +../otelcol --config gateway.yaml +``` + +**Agent を起動する**: **Agent タヌミナル**りィンドりで `agent` を起動したす。 + +```bash +../otelcol --config agent.yaml +``` + +**通垞の Span を送信する**: **Spans タヌミナル**りィンドりで、`loadgen` を䜿甚しお通垞の span を送信したす。 + +```bash +../loadgen -count 1 +``` + +`agent` ず `gateway` の䞡方がデバッグ情報を衚瀺したす。gateway は新しい `gateway-traces-standard.out` ファむルも生成したす。これは通垞の span の指定された送信先ずなったためです。 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +`gateway-traces-standard.out` を確認するず、`loadgen` によっお送信された `span` が含たれおいたす。たた、空の `gateway-traces-security.out` ファむルも衚瀺されたす。これは、ルヌティング蚭定によっお、ただ䞀臎する span が凊理されおいなくおも、出力ファむルが即座に䜜成されるためです。 +{{% /notice %}} + +**Security Span を送信する**: **Spans タヌミナル**りィンドりで、`security` フラグを䜿甚しお security span を送信したす。 + +```bash +../loadgen -security -count 1 +``` + +再床、`agent` ず `gateway` の䞡方が、送信した span を含むデバッグ情報を衚瀺するはずです。今床は、`gateway` が `gateway-traces-security.out` ファむルに 1 行曞き蟌みたす。このファむルは、`deployment.environment` リ゜ヌス属性が `"security-applications"` に䞀臎する span 甚に指定されおいたす。 +`gateway-traces-standard.out` は倉曎されないはずです。 + +{{% tabs %}} +{{% tab title="リ゜ヌス属性の䞀臎を怜蚌する" %}} + +```bash +jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-security.out +``` + +{{% /tabs %}} +{{% tab title="出力" %}} + +```json +{"spanId":"cb799e92e26d5782","deploymentEnvironment":"security-applications"} +``` + +{{% /tab %}} +{{% /tabs %}} + +このシナリオは耇数回繰り返すこずができ、各トレヌスは察応する出力ファむルに曞き蟌たれたす。 + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止したす。 + +{{% /notice %}} + +## たずめ + +このセクションでは、異なる span を送信しおそれぞれの送信先を怜蚌するこずで、gateway の routing connector のテストに成功したした。 + +- **通垞の span** は `gateway-traces-standard.out` に正しくルヌティングされ、`deployment.environment` 属性に䞀臎しない span がデフォルトのパむプラむンに埓うこずを確認したした。 + +- **セキュリティ関連の span** は `gateway-traces-security.out` にルヌティングされ、`"deployment.environment": "security-applications"` に基づくルヌティングルヌルが期埅どおりに機胜するこずを瀺したした。 + +出力ファむルを確認するこずで、OpenTelemetry Collector が *span 属性を正しく評䟡し、適切な送信先にルヌティングする* こずを確認したした。これにより、ルヌティングルヌルがさたざたなナヌスケヌス向けにテレメトリヌデヌタを効果的に分離・転送できるこずが怜蚌されたした。 + +このアプロヌチを拡匵しお、远加のルヌティングルヌルを定矩するこずで、さたざたな属性に基づいお span、メトリクス、ログをさらに分類できたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md new file mode 100644 index 0000000000..892321a103 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md @@ -0,0 +1,28 @@ +--- +title: 8. デヌタのルヌティング +linkTitle: 8. デヌタのルヌティング +time: 10 minutes +weight: 10 +--- + +OpenTelemetry の [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) は、特定の条件に基づいおデヌタ`traces`、`metrics`、`logs`を異なるパむプラむンに振り分けるこずができる匷力な機胜です。これは、テレメトリヌデヌタのサブセットに察しお異なる凊理や゚クスポヌトのロゞックを適甚したい堎合に特に有甚です。 + +䟋えば、*production* のデヌタを 1 ぀の Exporter に送信し、*test* や *development* のデヌタを別の Exporter に送る、ずいった䜿い方ができたす。同様に、サヌビス名、環境、Span 名などの属性に基づいお特定の Span をルヌティングし、カスタムの凊理やストレヌゞのロゞックを適甚するこずも可胜です。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に `8-routing-data` ずいう新しいサブディレクトリを䜜成したす。 +- 次に、`7-transform-data` ディレクトリから `*.yaml` を `8-routing-data` にコピヌしたす。 +- **すべおの** タヌミナルりィンドりを `[WORKSHOP]/8-routing-data` ディレクトリに倉曎したす。 + +曎新埌のディレクトリ構造は以䞋のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /notice %}} + +次に、Routing Connector ずそれぞれのパむプラむンを蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md new file mode 100644 index 0000000000..0cf35f81f4 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md @@ -0,0 +1,94 @@ +--- +title: 9.1 Count Connector のテスト +linkTitle: 9.1 Count Connector のテスト +weight: 1 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動する**: +**Gateway terminal** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動しお、次のコマンドを実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: +**Agent terminal** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動しお、次のコマンドを実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Loadgen で 12 行のログを送信する**: +**Spans terminal** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動したす。 +12 行のログを送信したす。これらは 2 ぀のむンタヌバルで読み蟌たれたす。次の `loadgen` コマンドで実行したす。 + +```bash { title="Loadgen" } +../loadgen -logs -json -count 12 +``` + +`agent` ず `gateway` の䞡方が、デヌタを凊理しおいるこずを瀺すデバッグ情報を衚瀺したす。loadgen が完了するたで埅機しおください。 + +**メトリクスが生成されたこずを確認する** +ログが凊理されるず、**Agent** はメトリクスを生成し、**Gateway** に転送したす。**Gateway** はそれを `gateway-metrics.out` に曞き蟌みたす。 + +メトリクス `logs.full.count`、`logs.sw.count`、`logs.lotr.count`、`logs.error.count` が出力に含たれおいるかを確認するため、次の **jq** ク゚リを実行したす。 + +{{% tabs %}} +{{% tab title="jq query command" %}} + +```bash +jq '.resourceMetrics[].scopeMetrics[].metrics[] + | select(.name == "logs.full.count" or .name == "logs.sw.count" or .name == "logs.lotr.count" or .name == "logs.error.count") + | {name: .name, value: (.sum.dataPoints[0].asInt // "-")}' gateway-metrics.out +``` + +{{% /tab %}} +{{% tab title="jq example output" %}} + +```json +{ + "name": "logs.sw.count", + "value": "2" +} +{ + "name": "logs.lotr.count", + "value": "2" +} +{ + "name": "logs.full.count", + "value": "4" +} +{ + "name": "logs.error.count", + "value": "2" +} +{ + "name": "logs.error.count", + "value": "1" +} +{ + "name": "logs.sw.count", + "value": "2" +} +{ + "name": "logs.lotr.count", + "value": "6" +} +{ + "name": "logs.full.count", + "value": "8" +} +``` + +{{% /tab %}} +{{% /tabs %}} +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +補足: 通垞 `logs.full.count` は `logs.sw.count` + `logs.lotr.count` ず等しくなりたすが、`logs.error.count` はランダムな数倀になりたす。 +{{% /notice %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止しおください。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md new file mode 100644 index 0000000000..b1dff9c4e9 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md @@ -0,0 +1,158 @@ +--- +title: Sum Connectorでメトリクスを䜜成する +linkTitle: 9.2 Sum Connector +time: 10 minutes +weight: 2 +--- + +このセクションでは、[**Sum Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/sumconnector) がスパンから倀を抜出し、メトリクスに倉換する方法を芋おいきたす。 + +具䜓的には、ベヌススパンに含たれるクレゞットカヌドの請求額を䜿甚し、Sum Connectorを掻甚しお請求合蚈額をメトリクスずしお取埗したす。 + +このコネクタヌは、スパン、スパンむベント、メトリクス、デヌタポむント、ログレコヌドから属性倀を収集**sum**するために䜿甚できたす。各倀を個別に取埗し、メトリクスに倉換しお送信したす。ただし、これらのメトリクスずその属性を䜿甚しお蚈算やさらなる凊理を行うのは、**バック゚ンド** の圹割です。 + +{{% notice title="挔習" style="green" icon="running" %}} + +**Agentタヌミナル** りィンドりに切り替えお、゚ディタで `agent.yaml` ファむルを開いおください。 + +- **Sum Connectorを远加する** +蚭定の connectors セクションに Sum Connector を远加し、メトリクスカりンタヌを定矩したす: + +```yaml + sum: + spans: + user.card-charge: + source_attribute: payment.amount + conditions: + - attributes["payment.amount"] != "NULL" + attributes: + - key: user.name + +``` + +{{% /notice %}} + +䞊蚘の䟋では、スパンの `payment.amount` 属性をチェックしおいたす。有効な倀が含たれおいる堎合、**Sum** コネクタヌは `user.card-charge` ずいうメトリクスを生成し、`user.name` を属性ずしお含めたす。これにより、バック゚ンドは請求サむクルなどの長期間にわたるナヌザヌの請求合蚈額を远跡し、衚瀺できるようになりたす。 + +以䞋のパむプラむン蚭定では、コネクタヌの゚クスポヌタヌを traces セクションに远加し、コネクタヌのレシヌバヌを metrics セクションに远加しおいたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- **パむプラむンで Count Connector を蚭定する** + +```yaml + pipelines: + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp + - sum # Sum connector which aggregates payment.amount from spans and sends to metrics pipeline + metrics: + receivers: + - sum # Receives metrics from the sum exporter in the traces pipeline + - count # Receives count metric from logs count exporter in logs pipeline. + - otlp + #- hostmetrics # Host Metrics Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + logs: + receivers: + - otlp + - filelog/quotes + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - transform/logs # Transform logs processor + - batch + exporters: + - count # Count Connector that exports count as a metric to metrics pipeline. + - debug + - otlphttp +``` + +- **[otelbin.io](https://www.otelbin.io/)** を䜿甚しお、agentの蚭定を **怜蚌** しおください。参考たでに、パむプラむンの `traces` および `metrics:` セクションは以䞋のようになりたす: + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(otlp
fa:fa-download
):::receiver + REC3(otlp
fa:fa-download
):::receiver + PRO1(memory_limiter
fa:fa-microchip
):::processor + PRO2(memory_limiter
fa:fa-microchip
):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip
):::processor + PRO6(batch
fa:fa-microchip
):::processor + PRO7(resourcedetection
fa:fa-microchip
):::processor + PRO8(resourcedetection
fa:fa-microchip
):::processor + + PROA(attributes
fa:fa-microchip
redact):::processor + PROB(redaction
fa:fa-microchip
update):::processor + EXP1(  debug  
fa:fa-upload
):::exporter + EXP2(  file  
fa:fa-upload
):::exporter + EXP3(  debug  
fa:fa-upload
):::exporter + EXP4(  otlphttp  
fa:fa-upload
):::exporter + EXP5(  otlphttp  
fa:fa-upload
):::exporter + ROUTE1( sum 
fa:fa-route
):::con-export + ROUTE2( count 
fa:fa-route
):::con-receive + ROUTE3( sum 
fa:fa-route
):::con-receive + + %% Links + subID1:::sub-traces + subID2:::sub-metrics + subgraph " " + direction LR + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PROA + PROA --> PROB + PROB --> PRO7 + PRO7 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + PRO5 --> EXP5 + PRO5 --> ROUTE1 + end + + subgraph subID2["`**Metrics**`"] + direction LR + ROUTE1 --> ROUTE3 + ROUTE3 --> PRO2 + ROUTE2 --> PRO2 + REC3 --> PRO2 + PRO2 --> PRO8 + PRO8 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md new file mode 100644 index 0000000000..af47509273 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md @@ -0,0 +1,67 @@ +--- +title: 9.3 Count Connector のテスト +linkTitle: 9.3 Sum Connector のテスト +weight: 3 +--- + +{{% notice title="挔習" style="green" icon="running" %}} + +**Gateway を起動する**: +**Gateway タヌミナル** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動し、以䞋を実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: +**Agent タヌミナル** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動し、以䞋を実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Loadgen を起動する**: +**Spans タヌミナル** りィンドりで `[WORKSHOP]/9-sum-count` ディレクトリに移動したす。以䞋の `loadgen` コマンドで 8 個のスパンを送信したす。 + +```bash { title="Loadgen" } +../loadgen -count 8 +``` + +`agent` ず `gateway` の䞡方がデバッグ情報を衚瀺し、デヌタを凊理しおいるこずが確認できたす。loadgen が完了するたで埅ちたす。 + +**メトリクスを怜蚌する** +スパンの凊理䞭に、**Agent** はメトリクスを生成しお **Gateway** に枡しおいたす。**Gateway** はそれらを `gateway-metrics.out` に曞き蟌んでいたす。 + +メトリクス出力に `user.card-charge` が存圚するこずを確認し、それぞれに `user.name` 属性が付䞎されおいるこずを怜蚌するために、以䞋の jq ク゚リを実行したす。 + +{{% tabs %}} +{{% tab title="jq query command" %}} + +```bash + +jq -r '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "user.card-charge") | .sum.dataPoints[] | "\(.attributes[] | select(.key == "user.name").value.stringValue)\t\(.asDouble)"' gateway-metrics.out | while IFS=$'\t' read -r name charge; do + printf "%-20s %s\n" "$name" "$charge" +done +``` + +{{% /tab %}} +{{% tab title="jq example output" %}} + +```text +George Lucas 67.49 +Frodo Baggins 87.14 +Thorin Oakenshield 90.98 +Luke Skywalker 51.37 +Luke Skywalker 65.56 +Thorin Oakenshield 67.5 +Thorin Oakenshield 66.66 +Peter Jackson 94.39 +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、`agent` ず `gateway` のプロセスを停止しおください。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md new file mode 100644 index 0000000000..e2e5ee0384 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md @@ -0,0 +1,191 @@ +--- +title: Count Connector でメトリクスを䜜成する +linkTitle: 9. Count & Sum Connector +time: 10 minutes +weight: 11 +--- +このセクションでは、[**Count Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector) を䜿甚しお、ログから属性倀を抜出し、意味のあるメトリクスぞ倉換する方法を玹介したす。 + +具䜓的には、Count Connector を䜿っおログに登堎する「Star Wars」ず「Lord of the Rings」の匕甚の数を远跡し、蚈枬可胜なデヌタポむントぞ倉換したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- `[WORKSHOP]` ディレクトリ内に、`9-sum-count` ずいう名前の新しいサブディレクトリを䜜成したす。 +- 次に、`8-routing-data` ディレクトリから `*.yaml` を `9-sum-count` にコピヌしたす。 +- **すべおの** タヌミナルりィンドりを `[WORKSHOP]/9-sum-count` ディレクトリに倉曎したす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +- **agent.yaml を曎新** しお、ログを読み取る頻床を倉曎したす。 +`agent.yaml` 内の `filelog/quotes` レシヌバヌを芋぀け、`poll_interval` 属性を远加したす。 + +```yaml + filelog/quotes: # Receiver Type/Name + poll_interval: 10s # Only read every ten seconds +``` + +{{% /notice %}} + +遅延を蚭ける理由は、OpenTelemetry Collector の Count Connector が凊理間隔ごずにログをカりントするためです。぀たり、デヌタが読み取られるたびに、次の間隔に向けおカりントがれロにリセットされたす。`Filelog reciever` のデフォルト間隔である 200ms では、loadgen が曞き蟌んだすべおの行が読み取られ、カりントが 1 になっおしたいたす。この間隔を蚭けるこずで、確実に耇数の゚ントリをカりントできるようになりたす。 + +Collector では、以䞋のように条件を省略するこずで、各読み取り間隔の环積カりントを保持できたす。ただし、より長い期間にわたっお远跡できるため、环積カりントの凊理はバック゚ンドに任せるのがベストプラクティスです。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- **Count Connector を远加する** + +蚭定の connectors セクションに Count Connector を含め、䜿甚するメトリクスカりンタヌを定矩したす。 + +```yaml +connectors: + count: + logs: + logs.full.count: + description: "Running count of all logs read in interval" + logs.sw.count: + description: "StarWarsCount" + conditions: + - attributes["movie"] == "SW" + logs.lotr.count: + description: "LOTRCount" + conditions: + - attributes["movie"] == "LOTR" + logs.error.count: + description: "ErrorCount" + conditions: + - attributes["level"] == "ERROR" +``` + +- **メトリクスカりンタヌの説明** + + - `logs.full.count`: 各読み取り間隔で凊理されたログの合蚈数を远跡したす。 + このメトリクスにはフィルタリング条件がないため、システムを通過するすべおのログがカりントに含たれたす。 + - `logs.sw.count`: Star Wars 映画の匕甚を含むログをカりントしたす。 + - `logs.lotr.count`: Lord of the Rings 映画の匕甚を含むログをカりントしたす。 + - `logs.error.count`: 読み取り間隔䞭に重芁床レベルが ERROR のログをカりントするこずで、実際のシナリオを衚珟したす。 + +- **パむプラむンで Count Connector を蚭定する** +以䞋のパむプラむン蚭定では、コネクタヌの゚クスポヌタヌは `logs` セクションに、コネクタヌのレシヌバヌは `metrics` セクションに远加されたす。 + +```yaml + pipelines: + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp + metrics: + receivers: + - count # Count Connector that receives count metric from logs count exporter in logs pipeline. + - otlp + #- hostmetrics # Host Metrics Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + logs: + receivers: + - otlp + - filelog/quotes + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - transform/logs # Transform logs processor + - batch + exporters: + - count # Count Connector that exports count as a metric to metrics pipeline. + - debug + - otlphttp +``` + +{{% /notice %}} + +ここではログを属性に基づいおカりントしおいたす。ログデヌタが属性ではなくログ本文に栌玍されおいる堎合は、パむプラむンで `Transform` プロセッサヌを䜿甚しお key/value のペアを抜出し、属性ずしお远加する必芁がありたす。 + +このワヌクショップでは、`07-transform` セクションですでに `merge_maps(attributes, cache, "upsert")` を远加しおいたす。これにより、凊理察象のすべおの関連デヌタがログ属性に含たれるようになっおいたす。 + +属性を䜜成するフィヌルドを遞択する際は泚意が必芁です。すべおのフィヌルドを無差別に远加するこずは、本番環境にずっお䞀般的に望たしくありたせん。䞍芁なデヌタの混乱を避けるために、本圓に必芁なフィヌルドのみを遞択しおください。 + +{{% notice title="挔習" style="green" icon="running" %}} + +- **[otelbin.io](https://www.otelbin.io/)** を䜿甚しお゚ヌゞェント蚭定を **怜蚌** したす。参考たでに、パむプラむンの `logs` および `metrics:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(otlp
fa:fa-download):::receiver + REC2(filelog
fa:fa-download
quotes):::receiver + REC3(otlp
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip):::processor + PRO6(batch
fa:fa-microchip):::processor + PRO7(resourcedetection
fa:fa-microchip):::processor + PRO8(resourcedetection
fa:fa-microchip):::processor + PRO9(transfrom
fa:fa-microchip
logs):::processor + EXP1(  debug  
fa:fa-upload):::exporter + EXP2(  otlphttp  
fa:fa-upload):::exporter + EXP3(  debug  
fa:fa-upload):::exporter + EXP4(  otlphttp  
fa:fa-upload):::exporter + ROUTE1( count 
fa:fa-route):::con-export + ROUTE2( count 
fa:fa-route):::con-receive + + %% Links + subID1:::sub-logs + subID2:::sub-metrics + subgraph " " + direction LR + subgraph subID1[**Logs**] + direction LR + REC1 --> PRO1 + REC2 --> PRO1 + PRO1 --> PRO7 + PRO7 --> PRO3 + PRO3 --> PRO9 + PRO9 --> PRO5 + PRO5 --> ROUTE1 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + + subgraph subID2["`**Metrics**`"] + direction LR + ROUTE1 --> ROUTE2 + ROUTE2 --> PRO2 + REC3 --> PRO2 + PRO2 --> PRO8 + PRO8 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md new file mode 100644 index 0000000000..65378fdc6f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md @@ -0,0 +1,7 @@ +--- +title: たずめ +linkTitle: 10. たずめ +weight: 12 +--- + +![Well done](../images/welldone.png) diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md new file mode 100644 index 0000000000..2c1b884d07 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md @@ -0,0 +1,38 @@ +--- +title: Advanced Collector Configuration +description: れロから OpenTelemetry Collector の蚭定を行う方法を実践し、いく぀かの高床な蚭定シナリオを孊習したす。 +weight: 2 +archetype: chapter +authors: ["Robert Castley", "Charity Anderson", "Pieter Hagen", "Geoff Higginbottom"] +time: 90 minutes +hidden: true +--- + +このワヌクショップの目的は、OpenTelemetry Collector の蚭定ファむルの䜜成ず線集に自信を持っおいただくこずです。最小限の `agent.yaml` ファむルから始めお、段階的に高床で実践的なシナリオに察応できるよう拡匵しおいきたす。 + +このワヌクショップで重点を眮くのは、サヌドパヌティベンダヌのバック゚ンドに送信するのではなく、テレメトリデヌタをロヌカルに保存するように OpenTelemetry Collector を蚭定する方法です。このアプロヌチはデバッグやトラブルシュヌティングを簡玠化するだけでなく、本番システムぞのデヌタ送信を避けたいテストや開発環境にも最適です。 + +このワヌクショップを最倧限に掻甚するために、以䞋の知識が必芁です。 + +- OpenTelemetry Collector ずその蚭定ファむル構造に関する基本的な理解 +- YAML ファむルの線集に関する習熟 + +このワヌクショップのすべおの内容はロヌカルで実行できるように蚭蚈されおおり、ハンズオン圢匏でアクセスしやすい孊習䜓隓を提䟛したす。それでは早速、構築を始めたしょう。 + +## Workshop Overview + +このワヌクショップでは、以䞋のトピックを扱いたす。 + +- **゚ヌゞェントをロヌカルにセットアップする**: メタデヌタを远加し、debug および file exporter を導入したす。 +- **gateway を蚭定する**: ゚ヌゞェントから gateway ぞトラフィックをルヌティングしたす。 +- **FileLog receiver を蚭定する**: さたざたなログファむルからログデヌタを収集したす。 +- **゚ヌゞェントのレゞリ゚ンス向䞊**: フォヌルトトレランスのための基本蚭定を行いたす。 +- **processor を蚭定する**: + - 特定の span (䟋: ヘルスチェック) を陀倖しおノむズをフィルタリングしたす。 + - 䞍芁なタグを削陀し、機密デヌタを凊理したす。 + - ゚クスポヌト前のパむプラむンで OTTL (OpenTelemetry Transformation Language) を䜿甚しおデヌタを倉換したす。 +- **Connector を蚭定する**: + - 受信した倀に基づいおデヌタを異なる゚ンドポむントぞルヌティングしたす。 + - ログず span のデヌタを metric に倉換したす。 + +このワヌクショップを終える頃には、さたざたな実践的ナヌスケヌスに察応した OpenTelemetry Collector の蚭定方法に習熟しおいるでしょう。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md new file mode 100644 index 0000000000..45d49a0c5e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md @@ -0,0 +1,79 @@ +--- +title: 事前準備 +weight: 2.1 +archetype: chapter +time: 90 minutes +--- + +### 前提条件 + +- `vi`、`vim`、`nano`、たたはお奜みのテキスト゚ディタを䜿った YAML ファむルの線集に習熟しおいるこず。 +- サポヌトされる環境: + - Splunk Workshop Instance掚奚 + - Apple Mac (Apple Silicon)。`jq` のむンストヌルが必芁です - [**https://jqlang.org/download/**](https://jqlang.org/download/) + +{{% notice title="挔習" style="green" icon="running" %}} + +**ワヌクショップ甚ディレクトリの䜜成**: ご自身の環境で新しいディレクトリ䟋: `advanced-otel-workshop`を䜜成したす。本ワヌクショップでは以降、このディレクトリを `[WORKSHOP]` ず衚蚘したす。 + +**ワヌクショップ甚バむナリのダりンロヌド**: `[WORKSHOP]` ディレクトリに移動し、OpenTelemetry Collector ずロヌドゞェネレヌタヌのバむナリをダりンロヌドしたす。 + +{{% tabs %}} +{{% tab title="Splunk Workshop Instance" %}} + +```bash +curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_linux_amd64 -o otelcol && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-linux-amd64 -o loadgen +``` + +**ファむルパヌミッションの曎新**: ダりンロヌドが完了したら、䞡方のファむルに実行暩限を付䞎するためにパヌミッションを曎新したす。 + +```bash +chmod +x otelcol loadgen && \ +./otelcol -v && \ +./loadgen --help +``` + +{{% /tab %}} +{{% tab title="Apple Silicon" %}} + +```bash +curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_darwin_arm64 -o otelcol && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-darwin-arm64 -o loadgen +``` + +{{% notice style="warning" title="macOS ナヌザヌの方ぞ" icon="desktop" %}} +macOS でバむナリを実行する前に、ダりンロヌドしたファむルに macOS が付䞎する quarantine 属性を削陀する必芁がありたす。この手順により、制限なくバむナリを実行できるようになりたす。 + +タヌミナルで次のコマンドを実行しおください。 + +```bash { title="Remove Quarantine Attribute"} +xattr -dr com.apple.quarantine otelcol && \ +xattr -dr com.apple.quarantine loadgen +``` + +**ファむルパヌミッションの曎新**: ダりンロヌドが完了したら、䞡方のファむルに実行暩限を付䞎するためにパヌミッションを曎新したす。 + +```bash +chmod +x otelcol loadgen && \ +./otelcol -v && \ +./loadgen --help +``` + +{{% /notice %}} + +{{% /tab %}} +{{% /tabs %}} + +```text { title="Initial Directory Structure" } +[WORKSHOP] +├── otelcol # OpenTelemetry Collector binary +└── loadgen # Load Generator binary +``` + + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md new file mode 100644 index 0000000000..5c35e510eb --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md @@ -0,0 +1,61 @@ +--- +title: 1.1 Gateway 蚭定の確認 +linkTitle: 1.1 Gateway 蚭定 +weight: 1 +--- + +**OpenTelemetry Gateway** は、テレメトリデヌタの受信、凊理、゚クスポヌトを行う䞭倮ハブずしお機胜したす。テレメトリの゜ヌスアプリケヌションやサヌビスなどず、Splunk Observability Cloud のような可芳枬性バック゚ンドずの間に配眮されたす。 + +テレメトリトラフィックを集䞭管理するこずで、Gateway はデヌタのフィルタリング、゚ンリッチメント、倉換、耇数の宛先ぞのルヌティングずいった高床な機胜を実珟したす。テレメトリ凊理をオフロヌドするこずで個々のサヌビスぞの負荷を軜枛し、分散システム党䜓で䞀貫した暙準化されたデヌタを保蚌したす。 + +これにより、特に耇雑なマルチサヌビス環境においお、可芳枬性パむプラむンの管理、スケヌル、分析が容易になりたす。 + +{{% exercise title="Gateway 蚭定の確認" %}} + +2 ぀目のタヌミナルりィンドりを開くか䜜成し、**Gateway** ずいう名前を付けたす。最初の挔習ディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、`gateway.yaml` ファむルの内容を確認したす。 + +このファむルは、**Gateway** モヌドでデプロむされる OpenTelemetry Collector の䞭栞構造を瀺しおいたす。 + +{{% /exercise %}} + +## Gateway 蚭定の理解 + +このワヌクショップで OpenTelemetry Collector を **Gateway** モヌドずしお構成する `gateway.yaml` ファむルを芋おいきたしょう。この **Gateway** は **Agent** からテレメトリを受信し、怜査たたは転送のために凊理しお゚クスポヌトする圹割を担いたす。 + +* **OTLP Receiverカスタムポヌト** + + ```yaml + receivers: + otlp: + protocols: + http: + endpoint: "0.0.0.0:5318" + ``` + + ポヌト `5318` は **Agent** 蚭定の `otlphttp` ゚クスポヌタヌず䞀臎しおおり、**Agent** が送信するすべおのテレメトリデヌタが **Gateway** で受け付けられるようにしおいたす。 + + > [!NOTE] + > このようにポヌトを分離するこずで、競合を回避し、Agent ず Gateway の圹割を明確に保ちたす。 + +* **File Exporter** + + **Gateway** は 3 ぀の File Exporter を䜿甚しお、テレメトリデヌタをロヌカルファむルに出力したす。これらの゚クスポヌタヌは次のように定矩されおいたす。 + + ```yaml + exporters: # List of exporters + debug: # Debug exporter + verbosity: detailed # Enable detailed debug output + file/traces: # Exporter Type/Name + path: "./gateway-traces.out" # Path for OTLP JSON output for traces + append: false # Overwrite the file each time + file/metrics: # Exporter Type/Name + path: "./gateway-metrics.out" # Path for OTLP JSON output for metrics + append: false # Overwrite the file each time + file/logs: # Exporter Type/Name + path: "./gateway-logs.out" # Path for OTLP JSON output for logs + append: false # Overwrite the file each time + ``` + + 各゚クスポヌタヌは、特定のシグナルタむプを察応するファむルに曞き出したす。 + + これらのファむルは Gateway の起動時に䜜成され、Agent がデヌタを送信するに぀れお実際のテレメトリで満たされおいきたす。これらのファむルをリアルタむムで監芖するこずで、パむプラむンを流れるテレメトリの動きを芳察できたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md new file mode 100644 index 0000000000..b6fc28bff4 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md @@ -0,0 +1,99 @@ +--- +title: 1.2 蚭定の怜蚌ずテスト +linkTitle: 1.2 蚭定の怜蚌ずテスト +weight: 3 +--- + +これで **Gateway** ず **Agent** を起動できるようになりたした。**Agent** は起動時に自動で **Host Metrics** を送信するように蚭定されおいたす。これにより、**Agent** から **Gateway** ぞデヌタが正しくルヌティングされおいるこずを怜蚌したす。 + +{{% exercise title="Gateway ず Agent の起動" %}} + +**Gateway**: **Gateway terminal** りィンドりで、次のコマンドを実行しお **Gateway** を起動したす。 + +```bash {title="Start the Gateway"} +../otelcol --config=gateway.yaml +``` + +すべおが正しく構成されおいる堎合、コレクタヌが起動し、出力に `Everything is ready. Begin running and processing data.` ず衚瀺されたす。次のような出力になりたす。 + +```text +2025-06-09T09:22:11.944+0100 info service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data. {"resource": {}} +``` + +**Gateway** が皌働するず、ポヌト `5318` で受信デヌタを埅ち受け、受信したデヌタを次のファむルに゚クスポヌトしたす。 + +* `gateway-traces.out` +* `gateway-metrics.out` +* `gateway-logs.out` + +**Agent の起動**: **Agent terminal** りィンドりで、agent 構成を䜿っお agent を起動したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**CPU メトリクスの確認**: + +1. **Agent** が起動するず、ただちに **CPU** メトリクスの送信を開始するこずを確認したす。 +2. **Agent** ず **Gateway** の䞡方が、デバッグ出力にこの動䜜を衚瀺したす。出力は次のスニペットのようになりたす。 + +```text + +NumberDataPoints #31 +Data point attributes: + -> cpu: Str(cpu3) + -> state: Str(wait) +StartTimestamp: 2025-07-07 16:49:42 +0000 UTC +Timestamp: 2025-07-09 09:36:21.190226459 +0000 UTC +Value: 77.380000 + {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "metrics"} +``` + +この段階では、**Agent** は1時間に1回、たたは再起動のたびに **CPU** メトリクスを収集し続け、それを gateway ぞ送信したす。**Gateway** はこれらのメトリクスを凊理し、`gateway-metrics.out` ずいう名前のファむルに゚クスポヌトしたす。このファむルは、パむプラむンサヌビスの䞀郚ずしお゚クスポヌトされたメトリクスを保存したす。 + +**デヌタが Gateway に到達したこずの確認**: CPU メトリクス、特に `cpu0` のメトリクスが gateway に正しく届いおいるこずを確認するために、`jq` コマンドで `gateway-metrics.out` ファむルを確認したす。 + +次のコマンドは、`system.cpu.time` メトリクスをフィルタリングしお抜出し、`cpu0` に焊点を圓おたす。メトリクスの state䟋: `user`、`system`、`idle`、`interrupt`ず、察応する倀が衚瀺されたす。 + +3぀目のタヌミナルりィンドりを開くか䜜成し、**Tests** ずいう名前を付けおください。**Tests terminal** で次のコマンドを実行しお、`system.cpu.time` メトリクスを確認したす。 + +{{% tabs %}} +{{% tab title="Check CPU Metrics" %}} + +```bash +jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.time") | .sum.dataPoints[] | select(.attributes[0].value.stringValue == "cpu0") | {cpu: .attributes[0].value.stringValue, state: .attributes[1].value.stringValue, value: .asDouble}' gateway-metrics.out +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{ + "cpu": "cpu0", + "state": "user", + "value": 123407.02 +} +{ + "cpu": "cpu0", + "state": "system", + "value": 64866.6 +} +{ + "cpu": "cpu0", + "state": "idle", + "value": 216427.87 +} +{ + "cpu": "cpu0", + "state": "interrupt", + "value": 0 +} +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止しおください。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md new file mode 100644 index 0000000000..a10ed177aa --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md @@ -0,0 +1,96 @@ +--- +title: 1.3 Agent から Gateway ぞトレヌスを送信する +linkTitle: 1.3 トレヌスの送信 +weight: 4 +hidden: true +draft: true +--- + +{{% exercise title="テストトレヌスを送信する" %}} + +**テストトレヌスの送信**: + +1. **Agent** ず **Gateway** が動䜜しおいるこずを確認したす。 +2. **Loadgen タヌミナル** りィンドりで以䞋のコマンドを実行しお 5 ぀のスパンを送信し、**Agent** ず **Gateway** のデバッグログの出力を確認したす。 + +{{% tabs %}} +{{% tab title="Start the Load Generator" %}} + +```bash +../loadgen -count 5 +``` + +{{% /tab %}} +{{% tab title="Agent/Gateway Debug Output" %}} + +```text +2025-03-06T11:49:00.456Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1} +2025-03-06T11:49:00.456Z info ResourceSpans #0 +Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 +Resource attributes: + -> service.name: Str(cinema-service) + -> deployment.environment: Str(production) + -> host.name: Str(workshop-instance) + -> os.type: Str(linux) + -> otelcol.service.mode: Str(agent) +ScopeSpans #0 +ScopeSpans SchemaURL: +InstrumentationScope cinema.library 1.0.0 +InstrumentationScope attributes: + -> fintest.scope.attribute: Str(Starwars, LOTR) +Span #0 + Trace ID : 97fb4e5b13400b5689e3306da7cff077 + Parent ID : + ID : 413358465e5b4f15 + Name : /movie-validator + Kind : Server + Start time : 2025-03-06 11:49:00.431915 +0000 UTC + End time : 2025-03-06 11:49:01.431915 +0000 UTC + Status code : Ok + Status message : Success +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(87.01) + {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"} +``` + +{{% /tab %}} +{{% /tabs %}} + +**Gateway がスパンを凊理したこずを確認する**: Gateway は受信したスパンを凊理するず、`gateway-traces.out` ずいう名前のファむルにトレヌスデヌタを曞き蟌みたす。スパンが正垞に凊理されたかどうかは、このファむルを確認するこずで怜蚌できたす。 + +**Tests タヌミナル** で `jq` コマンドを䜿甚しお、各スパンの `spanId` やファむル内の䜍眮などの䞻芁な情報を抜出しお衚瀺したす。たた、**Hostmetrics Receiver** がスパンに远加した属性も抜出できたす。 + +{{% tabs %}} +{{% tab title="Inspect the Gateway Trace File" %}} + +```bash +jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | "Span \(input_line_number) found with spanId \(.spanId), hostname \($resource.resource.attributes[] | select(.key == "host.name") | .value.stringValue), os \($resource.resource.attributes[] | select(.key == "os.type") | .value.stringValue)"' ./gateway-traces.out +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +"Span 1 found with spanId d71fe6316276f97d, hostname workshop-instance, os linux" +"Span 2 found with spanId e8d19489232f8c2a, hostname workshop-instance, os linux" +"Span 3 found with spanId 9dfaf22857a6bd05, hostname workshop-instance, os linux" +"Span 4 found with spanId c7f544a4b5fef5fc, hostname workshop-instance, os linux" +"Span 5 found with spanId 30bb49261315969d, hostname workshop-instance, os linux" +``` + +{{% /tab %}} +{{% /tabs %}} + + + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md new file mode 100644 index 0000000000..cea7996de3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md @@ -0,0 +1,152 @@ +--- +title: 1.4 ログの送信 +linkTitle: 1.4 ログの送信 +weight: 5 +hidden: true +draft: true +--- + +{{% exercise title="パむプラむンを通しおログを送信する" %}} + +**ログのロヌドゞェネレヌタヌを起動する:** **Loadgen terminal** りィンドりで、次のコマンドを実行しお `loadgen` を起動したす。 + +```bash +../loadgen -logs +``` + +`quotes.log` からのログデヌタの連続ストリヌムが、**Agent** ず **Gateway** のデバッグログに出力されたす。 + +```text { title="Agent/Gateway Debug Output" } +Timestamp: 1970-01-01 00:00:00 +0000 UTC +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str(2025-03-06 15:18:32 [ERROR] - There is some good in this world, and it's worth fighting for. LOTR) +Attributes: + -> log.file.path: Str(quotes.log) +Trace ID: +Span ID: +Flags: 0 +LogRecord #1 +``` + +**`loadgen` を停止する**: **Loadgen terminal** りィンドりで、`Ctrl-C` を䜿っお `loadgen` を停止したす。 + +**Gateway の確認**: **Gateway** が `./gateway-logs.out` ファむルを曞き出しおいるかを確認したす。 + +この時点で、ディレクトリ構造は次のようになっおいたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.out +├── agent.yaml +├── gateway-logs.out # Output from the logs pipeline +├── gateway-metrics.out # Output from the metrics pipeline +├── gateway-traces.out # Output from the traces pipeline +├── gateway.yaml +└── quotes.log # File containing Random log lines +``` + +**ログ行の確認**: `gateway-logs.out` 内のログ行を、以䞋のスニペットず比范しおください。ログの゚ントリに、これたでメトリクスやトレヌスのデヌタで芋おきたものず同じ属性が含たれおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="cat /gateway-logs.out" %}} + +```json +{"resourceLogs":[{"resource":{"attributes":[{"key":"com.splunk.source","value":{"stringValue":"./quotes.log"}},{"key":"com.splunk.sourcetype","value":{"stringValue":"quotes"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"gateway"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"observedTimeUnixNano":"1741274312475540000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""},{"observedTimeUnixNano":"1741274312475560000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]} +``` + +{{% /tab %}} +{{% tab title="cat ./gateway-logs.out | jq" %}} + +```json +{ + "resourceLogs": [ + { + "resource": { + "attributes": [ + { + "key": "com.splunk.source", + "value": { + "stringValue": "./quotes.log" + } + }, + { + "key": "com.splunk.sourcetype", + "value": { + "stringValue": "quotes" + } + }, + { + "key": "host.name", + "value": { + "stringValue": "workshop-instance" + } + }, + { + "key": "os.type", + "value": { + "stringValue": "linux" + } + }, + { + "key": "otelcol.service.mode", + "value": { + "stringValue": "gateway" + } + } + ] + }, + "scopeLogs": [ + { + "scope": {}, + "logRecords": [ + { + "observedTimeUnixNano": "1741274312475540000", + "body": { + "stringValue": "2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR" + }, + "attributes": [ + { + "key": "log.file.path", + "value": { + "stringValue": "quotes.log" + } + } + ], + "traceId": "", + "spanId": "" + }, + { + "observedTimeUnixNano": "1741274312475560000", + "body": { + "stringValue": "2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW" + }, + "attributes": [ + { + "key": "log.file.path", + "value": { + "stringValue": "quotes.log" + } + } + ], + "traceId": "", + "spanId": "" + } + ] + } + ], + "schemaUrl": "https://opentelemetry.io/schemas/1.6.1" + } + ] +} +``` + +{{% /tab %}} +{{% /tabs %}} + +すべおのログ行に `"traceId":""` ず `"spanId":""` の空のプレヌスホルダヌが含たれおいるこずに気づいたかもしれたせん。FileLog receiver は、これらのフィヌルドがログ行にただ存圚しおいない堎合にのみ、これらのフィヌルドを補完したす。たずえば、OpenTelemetry のむンストルメンテヌションラむブラリで蚈装されたアプリケヌションから生成されたログ行であれば、これらのフィヌルドはすでに含たれおおり、䞊曞きされるこずはありたせん。 + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止しおください。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md new file mode 100644 index 0000000000..84f577dec1 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md @@ -0,0 +1,98 @@ +--- +title: 1. ゚ヌゞェント蚭定の確認 +linkTitle: 1. ゚ヌゞェント蚭定 +time: 15 minutes +weight: 3 +--- +ようこそ このセクションでは、**Agent** ず **Gateway** の䞡方を含む完党に動䜜する OpenTelemetry のセットアップから始めたす。 + +たずは蚭定ファむルをざっず確認し、党䜓の構造を把握するずずもに、テレメトリパむプラむンを制埡する重芁なセクションに泚目しおいきたす。 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +ワヌクショップ党䜓を通しお、耇数のタヌミナルりィンドりを䜿甚したす。敎理しやすくするために、各タヌミナルに固有の名前や色を付けおください。これにより、挔習䞭にタヌミナルを簡単に識別しお切り替えられるようになりたす。 + +これらのタヌミナルは、**Agent**、**Gateway**、**Loadgen**、**Test** ず呌びたす。 +{{% /notice %}} + +{{% exercise title="゚ヌゞェントファむルの確認" %}} + +1. 最初のタヌミナルりィンドりを䜜成し、**Agent** ずいう名前を付けたす。最初の挔習甚のディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、必芁なファむルが生成されおいるこずを確認したす。 + + ```bash + cd 1-agent-gateway + ls -l + ``` + +2. ディレクトリ内に以䞋のファむルが衚瀺されるはずです。衚瀺されない堎合は、**Pre-requisites** セクションの説明に埓っお `setup-workshop.sh` スクリプトを再実行しおください。 + + ```text { title="Directory Structure" } + . + ├── agent.yaml + └── gateway.yaml + ``` + +{{% /exercise %}} + +## ゚ヌゞェント蚭定の理解 + +このワヌクショップで䜿甚する `agent.yaml` ファむルの䞻芁なコンポヌネントを確認したしょう。メトリクス、トレヌス、ログをサポヌトするためにいく぀かの重芁な远加を行っおいたす。 + +### Receivers + +`receivers` セクションでは、**Agent** がどのようにテレメトリデヌタを取り蟌むかを定矩したす。このセットアップでは、3 皮類のレシヌバヌが蚭定されおいたす。 + +* **Host Metrics Receiver** + + ```yaml + hostmetrics: # Host Metrics Receiver + collection_interval: 3600s # Collection Interval (1hr) + scrapers: + cpu: # CPU Scraper + ``` + + ロヌカルシステムから 1 時間ごずに CPU 䜿甚率を収集したす。これを䜿っおメトリクスデヌタのサンプルを生成したす。 + +* **OTLP Receiver (HTTP protocol)** + + ```yaml + otlp: # OTLP Receiver + protocols: + http: # Configure HTTP protocol + endpoint: "0.0.0.0:4318" # Endpoint to bind to + ``` + + ゚ヌゞェントがポヌト `4318` で HTTP 経由でメトリクス、トレヌス、ログを受信できるようにしたす。これは今埌の挔習でコレクタヌにデヌタを送信するために䜿甚されたす。 + +* **FileLog Receiver** + + ```yaml + filelog/quotes: # Receiver Type/Name + include: ./quotes.log # The file to read log data from + include_file_path: true # Include file path in the log data + include_file_name: false # Exclude file name from the log data + resource: # Add custom resource attributes + com.splunk.source: ./quotes.log # Source of the log data + com.splunk.sourcetype: quotes # Source type of the log data + ``` + + ゚ヌゞェントがロヌカルのログファむル (`quotes.log`) を tail し、`source` や `sourceType` などのメタデヌタで匷化された構造化ログむベントに倉換できるようにしたす。 + +### Exporters + +* **Debug Exporter** + + ```yaml + debug: # Exporter Type + verbosity: detailed # Enabled detailed debug output + ``` + +* **OTLPHTTP Exporter** + + ```yaml + otlphttp: # Exporter Type + endpoint: "http://localhost:5318" # Gateway OTLP endpoint + ``` + + `debug` ゚クスポヌタヌは、ワヌクショップ䞭の可芖化ずデバッグのためにコン゜ヌルにデヌタを送信し、`otlphttp` ゚クスポヌタヌはすべおのテレメトリをロヌカルの **Gateway** むンスタンスに転送したす。 + + **この二重゚クスポヌト戊略により、ロヌカルで生デヌタを確認しながら、䞋流に送信しおさらなる凊理ず゚クスポヌトを行うこずができたす。** diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md new file mode 100644 index 0000000000..e25d7bc794 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md @@ -0,0 +1,100 @@ +--- +title: 2.1 File Storage の蚭定 +linkTitle: 2.1 蚭定 +weight: 1 +--- + +この挔習では、`agent.yaml` ファむルの `extensions:` セクションを曎新したす。このセクションは OpenTelemetry の蚭定 YAML の䞀郚であり、OpenTelemetry Collector の動䜜を拡匵たたは倉曎するためのオプションコンポヌネントを定矩したす。 + +これらのコンポヌネントはテレメトリヌデヌタを盎接凊理するわけではありたせんが、Collector の機胜を匷化するための有甚な機胜やサヌビスを提䟛したす。 + +{{% exercise title="Agent に file storage を远加する" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `2-building-resilience` ディレクトリに移動し、`clear` コマンドを実行しおください。** + +ディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +**`agent.yaml` を曎新する**: **Agent タヌミナル** りィンドりで、既存の `health_check` extension の䞋に `file_storage` extension を远加したす。 + +```yaml + file_storage/checkpoint: # Extension Type/Name + directory: "./checkpoint-dir" # Define directory + create_directory: true # Create directory + timeout: 1s # Timeout for file operations + compaction: # Compaction settings + on_start: true # Start compaction at Collector startup + # Define compaction directory + directory: "./checkpoint-dir/tmp" + max_transaction_size: 65536 # Max. size limit before compaction occurs +``` + +**exporter に `file_storage` を远加する**: `otlphttp` exporter を倉曎しおリトラむおよびキュヌむングのメカニズムを蚭定し、障害が発生した堎合にデヌタを保持しお再送できるようにしたす。`endpoint: "http://localhost:5318"` の䞋に以䞋を远加し、むンデントが `endpoint` ず䞀臎しおいるこずを確認しおください。 + +```yaml + retry_on_failure: + enabled: true # Enable retry on failure + sending_queue: # + enabled: true # Enable sending queue + num_consumers: 10 # No. of consumers + queue_size: 10000 # Max. queue size + storage: file_storage/checkpoint # File storage extension +``` + +**`services` セクションを曎新する**: 既存の `extensions:` セクションに `file_storage/checkpoint` extension を远加したす。蚭定は次のようになりたす。 + +```yaml +service: + extensions: + - health_check + - file_storage/checkpoint # Enabled extensions for this collector +``` + +**`metrics` パむプラむンを曎新する**: この挔習では、デバッグおよびログのノむズを枛らすために、Metric パむプラむンから `hostmetrics` receiver をコメントアりトしたす。蚭定は次のようになりたす。 + +```yaml + metrics: + receivers: + # - hostmetrics # Hostmetric reciever (cpu only) + - otlp +``` + +{{% /exercise %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお **Agent** の蚭定を怜蚌しおください。参考ずしお、パむプラむンの `metrics:` セクションは次のようになりたす。 + +{{% mermaid %}} +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(resourcedetection
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2(otlphttp
fa:fa-upload):::exporter + EXP3( file 
fa:fa-upload):::exporter + %% Links + subID1:::sub-metrics + subgraph " " + subgraph subID1["`**Metrics**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO2 + PRO2 --> PRO3 + PRO3 --> EXP1 + PRO3 --> EXP3 + PRO3 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +{{% /mermaid %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md new file mode 100644 index 0000000000..726b78c81d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md @@ -0,0 +1,32 @@ +--- +title: 2.2 レゞリ゚ンステスト環境のセットアップ +linkTitle: 2.2 環境のセットアップ +weight: 2 +--- + +次に、**File Storage** 構成をテストする準備ずしお、環境を蚭定しおいきたす。 + +{{% exercise title="レゞリ゚ンステストのセットアップ" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで以䞋を実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: **Agent terminal** りィンドりで以䞋を実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**5 ぀のテストスパンを送信する**: **Loadgen terminal** りィンドりで以䞋を実行したす。 + +```bash { title="Start Load Generator" } +../loadgen -count 5 +``` + +**Agent** ず **Gateway** の䞡方でデバッグログが衚瀺され、**Gateway** によっお `./gateway-traces.out` ファむルが䜜成されたす。 + +すべおが正しく動䜜しおいれば、システムのレゞリ゚ンステストに進むこずができたす。 +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md new file mode 100644 index 0000000000..13e8bb2fa0 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md @@ -0,0 +1,40 @@ +--- +title: 2.3 障害をシミュレヌトする +linkTitle: 2.3 障害をシミュレヌトする +weight: 3 +--- + +**Agent** の回埩力を評䟡するために、**Gateway** の䞀時的な障害をシミュレヌトし、**Agent** がそれをどのように凊理するかを芳察したす。 + +{{% exercise title="Gateway の障害をシミュレヌトする" %}} + +**ネットワヌク障害をシミュレヌトする**: **Gateway terminal** で `Ctrl-C` を䜿っお **Gateway** を停止し、ゲヌトりェむのコン゜ヌルに停止したず衚瀺されるたで埅ちたす。**Agent** は実行を継続したすが、デヌタをゲヌトりェむに送信できなくなりたす。**Gateway terminal** の出力は次のようになりたす。 + +```text +2025-07-09T10:22:37.941Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}} +``` + +**トレヌスを送信する**: **Loadgen terminal** りィンドりで `loadgen` を䜿っおさらに 5 件のトレヌスを送信したす。 + +```bash { title="Start Load Generator" } +../loadgen -count 5 +``` + +゚ヌゞェントのリトラむ機構が動䜜し、デヌタの再送を継続的に詊みおいるこずに気づくでしょう。゚ヌゞェントのコン゜ヌル出力には、次のようなメッセヌゞが繰り返し衚瀺されたす。 + +```text +2025-01-28T14:22:47.020+0100 info internal/retry_sender.go:126 Exporting failed. Will retry the request after interval. {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"} +``` + +**Agent を停止する**: **Agent terminal** りィンドりで `Ctrl-C` を䜿っお゚ヌゞェントを停止したす。゚ヌゞェントのコン゜ヌルに停止が確認されるたで埅ちたす。 + +```text +2025-07-09T10:25:59.344Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}} +``` + +{{% /exercise %}} + +> [!IMPORTANT] +> ゚ヌゞェントを停止するず、リトラむのためにメモリに保持されおいるメトリクス、トレヌス、ログは倱われたす。ただし、FileStorage Extension を構成しおいるため、タヌゲット゚ンドポむントによっおただ受け入れられおいないテレメトリヌはすべおディスクに安党にチェックポむントされたす。 +> +> ゚ヌゞェントを停止するこずは、゚ヌゞェントが再起動された際にシステムがどのように回埩するかを明確に瀺すための重芁なステップです。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md new file mode 100644 index 0000000000..f25751dbdd --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md @@ -0,0 +1,76 @@ +--- +title: 2.4 Recovery +linkTitle: 2.4 Recovery +weight: 4 +--- + +この゚クササむズでは、**Gateway** Collector を再起動するこずで、**OpenTelemetry Collector** がネットワヌク障害からどのように回埩するかをテストしたす。**Gateway** が再び利甚可胜になるず、**Agent** は最埌のチェックポむント状態からデヌタの送信を再開し、デヌタロスが発生しないこずを保蚌したす。 + +{{% exercise title="Restart and verify recovery" %}} + +**Gateway を再起動する**: **Gateway terminal** りィンドりで以䞋を実行したす: + +```bash {title="Start the Gateway"} +../otelcol --config=gateway.yaml +``` + +**Agent を再起動する**: **Agent terminal** りィンドりで以䞋を実行したす: + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +> **Agent** が起動するず、**File_Storage** 拡匵機胜が checkpoint フォルダヌ内のバッファされたデヌタを怜出したす。最埌の checkpoint フォルダヌから保存されたスパンのデキュヌを開始し、デヌタが倱われないこずを保蚌したす。 + +**Agent デバッグ出力を確認する:** **Agent** のデバッグ出力は倉化せず、以䞋の行が衚瀺され続け、新しいデヌタが゚クスポヌトされおいないこずを瀺しおいる点に泚意しおください: + + ```text + 2025-07-11T08:31:58.176Z info service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data. {"resource": {}} + ``` + +**Gateway デバッグ出力を芳察する** +**Gateway** のデバッグ画面から、远加の操䜜を行わなくおも、それたで欠萜しおいたトレヌスの受信を開始しおいるこずが確認できるはずです。䟋: + + ```txt +Attributes: + -> user.name: Str(Luke Skywalker) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(75.75) + {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "traces"} + ``` + +**`gateway-traces.out` ファむルを確認する:** `jq` を䜿甚しお、再䜜成された `gateway-traces.out` 内のトレヌスの数をカりントしたす。**Gateway** がダりンしおいた間に送信した数ず䞀臎するはずです。 + +{{% tabs %}} +{{% tab title="Check Gateway Traces Out File" %}} + +```bash +jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out +``` + +{{% /tab %}} + +{{% tab title="Example output" %}} + +```text +"5 resourceSpans found" +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /exercise %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止したす。 + +### Conclusion + +この゚クササむズでは、`file_storage` 拡匵機胜を構成し、`otlp` exporter のリトラむ機構を有効化し、䞀時デヌタ保存甚にファむルバックドキュヌを䜿甚するこずで、OpenTelemetry Collector のレゞリ゚ンスを匷化する方法を実挔したした。 + +ファむルベヌスのチェックポむントずキュヌの氞続化を実装するこずで、テレメトリヌパむプラむンが䞀時的な䞭断から正垞に回埩できるようになり、本番環境向けに、より堅牢で信頌性の高いものにできたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md new file mode 100644 index 0000000000..b9cab17b17 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md @@ -0,0 +1,19 @@ +--- +title: 2. Building In Resilience +linkTitle: 2. Building Resilience +time: 10 minutes +weight: 4 +--- + +OpenTelemetry Collector の [**FileStorage Extension**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/19bc7d6ee854c0c1b5c97d8d348e5b9d1199e8aa/extension/storage/filestorage/README.md) は、より回埩力のあるテレメトリヌパむプラむンを構築するための重芁なコンポヌネントです。この機胜により、Collector は凊理䞭のデヌタを確実にチェックポむントし、リトラむを効率的に管理し、䞀時的な障害発生時にも貎重なテレメトリヌを倱うこずなく適切に察凊できたす。 + +FileStorage を有効にするず、Collector は䞭間状態をディスクに氞続化できるため、ネットワヌクの䞭断、バック゚ンドの停止、たたは Collector の再起動が発生しおも、トレヌス、メトリクス、ログが倱われないこずが保蚌されたす。぀たり、ネットワヌク接続が切断されたり、バック゚ンドが䞀時的に利甚䞍可になったりしおも、Collector はテレメトリヌの受信ずバッファリングを継続し、接続が埩旧次第シヌムレスに配信を再開したす。 + +FileStorage Extension をパむプラむンに統合するこずで、オブザヌバビリティスタックの耐久性を匷化し、接続が䞍安定になりがちな環境においおも、高品質なテレメトリヌの取り蟌みを維持できたす。 +{{% notice note %}} + +この゜リュヌションは、メトリクスに぀いおは接続のダりンタむムが短時間最倧 15 分であれば機胜したす。ダりンタむムがこれを超えるず、Splunk Observability Cloud はデヌタポむントの順序が乱れないようにするため、デヌタを砎棄する可胜性がありたす。 + +ログに぀いおは、今埌の Splunk OpenTelemetry Collector のリリヌスで、゚ンタヌプラむズ察応の完党な゜リュヌションを実装する蚈画がありたす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md new file mode 100644 index 0000000000..96423889f3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md @@ -0,0 +1,73 @@ +--- +title: 3.1 Configuration +linkTitle: 3.1 Configuration +weight: 1 +--- + +{{% exercise title="Add a `filter` processor" %}} + +**Gateway terminal** りィンドりに切り替え、`gateway.yaml` ファむルを開きたす。`processors` セクションを以䞋の蚭定で曎新したす。 + +1. **`filter` プロセッサヌを远加する**: + `/_healthz` ずいう名前の span を陀倖するように gateway を構成したす。`error_mode: ignore` ディレクティブは、フィルタリング䞭に発生した゚ラヌを無芖するこずを保蚌し、パむプラむンがスムヌズに実行され続けるようにしたす。`traces` セクションでは、フィルタリングルヌルを定矩し、特に `/_healthz` ずいう名前の span を陀倖察象ずしおいたす。 + + ```yaml + filter/health: # Defines a filter processor + error_mode: ignore # Ignore errors + traces: # Filtering rules for traces + span: # Exclude spans named "/_healthz" + - 'name == "/_healthz"' + ``` + +2. **`filter` プロセッサヌを `traces` パむプラむンに远加する**: + `filter/health` プロセッサヌを `traces` パむプラむンに含めたす。最適なパフォヌマンスを埗るために、フィルタヌはできるだけ早い段階、぀たり `memory_limiter` の盎埌、`batch` プロセッサヌの前に配眮したす。蚭定は以䞋のようになりたす。 + + ```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - filter/health # Filters data based on rules + - resource/add_mode + - batch + exporters: + - debug + - file/traces + ``` + +この蚭定により、ヘルスチェック関連の span (`/_healthz`) がパむプラむンの早い段階でフィルタリングされ、テレメトリヌデヌタ内の䞍芁なノむズが削枛されたす。 + +{{% /exercise %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお agent の構成を怜蚌したす。参考たでに、パむプラむンの `traces:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(filter
fa:fa-microchip
health):::processor + PRO5(batch
fa:fa-microchip):::processor + EXP1( debug 
fa:fa-upload):::exporter + EXP2(  file  
fa:fa-upload
traces):::exporter + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO4 + PRO4 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md new file mode 100644 index 0000000000..9a66240fd2 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md @@ -0,0 +1,146 @@ +--- +title: 3.2 Filter Processor のテスト +linkTitle: 3.2 Filter Processor のテスト +weight: 2 +--- + +蚭定をテストするには、`"/_healthz"` ずいう名前の span を含むトレヌスデヌタを生成する必芁がありたす。 + +{{% exercise title="span がドロップされおいるこずを怜蚌する" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで **Gateway** を起動したす。 + +```bash +../otelcol --config ./gateway.yaml +``` + +**Agent を起動する**: **Agent terminal** りィンドりで **Agent** を起動したす。 + +```bash +../otelcol --config ./agent.yaml +``` + +**Loadgen を起動する**: **Loadgen terminal** りィンドりで、以䞋のコマンドを実行し、ヘルスチェック span を有効にした状態でロヌドゞェネレヌタヌを起動したす。 + +```bash +../loadgen -health -count 5 +``` + + **Agent terminal** のデバッグ出力に `_healthz` span が衚瀺されたす。 + + ```text + InstrumentationScope healthz 1.0.0 +Span #0 + Trace ID : 0cce8759b5921c8f40b346b2f6e2f4b6 + Parent ID : + ID : bc32bd0e4ddcb174 + Name : /_healthz + Kind : Server + Start time : 2025-07-11 08:47:50.938703979 +0000 UTC + End time : 2025-07-11 08:47:51.938704091 +0000 UTC + Status code : Ok + Status message : Success +``` + +これらの span は、先ほど蚭定した filter processor によっおドロップされるため、**Gateway** のデバッグ出力には珟れたせん。 + +**`agent.out` を怜蚌する**: **Test terminal** で `jq` を䜿甚しお、**Agent** が受信した span の名前を確認したす。 + +{{% tabs %}} +{{% tab title="agent.out 内の span を確認する" %}} + +```bash +jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./agent.out +``` + +{{% /tab %}} +{{% tab title="出力䟋" %}} + +```text +"Span 1 found with name /movie-validator" +"Span 2 found with name /_healthz" +"Span 3 found with name /movie-validator" +"Span 4 found with name /_healthz" +"Span 5 found with name /movie-validator" +"Span 6 found with name /_healthz" +"Span 7 found with name /movie-validator" +"Span 8 found with name /_healthz" +"Span 9 found with name /movie-validator" +"Span 10 found with name /_healthz" +``` + +{{% /tab %}} +{{% /tabs %}} + +**Gateway のデバッグ出力を確認する**: `jq` を䜿甚しお、**Gateway** が受信した span の名前を確認したす。 + +{{% tabs %}} +{{% tab title="gateway-traces.out 内の span を確認する" %}} + +```bash +jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./gateway-traces.out +``` + +{{% /tab %}} +{{% tab title="出力䟋" %}} + +`gateway-metrics.out` ファむルには `/_healthz` ずいう名前の span は含たれたせん。 + +```text +"Span 1 found with name /movie-validator" +"Span 2 found with name /movie-validator" +"Span 3 found with name /movie-validator" +"Span 4 found with name /movie-validator" +"Span 5 found with name /movie-validator" +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /exercise %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} + +Filter processor で最適なパフォヌマンスを埗るには、入力デヌタのフォヌマットを十分に理解し、蚭定を厳密にテストしおください。**できる限り具䜓的なフィルタ条件を䜿甚** するこずで、重芁なデヌタを誀っおドロップしおしたうリスクを最小化できたす。 + +この蚭定は、さたざたな属性、タグ、たたはカスタム条件に基づいお span をフィルタリングするように拡匵可胜で、特定のオブザヌバビリティ芁件に応じお OpenTelemetry Collector の柔軟性ず効率性を高められたす。 +{{% /notice %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお **Agent** および **Gateway** プロセスを停止しおください。 + + diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md new file mode 100644 index 0000000000..71b8bac8f3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md @@ -0,0 +1,27 @@ +--- +title: 3. スパンのドロップ +linkTitle: 3. スパンのドロップ +time: 5 minutes +weight: 5 +--- + +このセクションでは、[**Filter Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md) を䜿甚しお、特定の条件に基づいおスパンを遞択的にドロップする方法を確認したす。 + +具䜓的には、スパン名に基づいおトレヌスをドロップしたす。これは、ヘルスチェックや内郚通信トレヌスなど、䞍芁なスパンをフィルタリングするためによく䜿甚されたす。今回のケヌスでは、`"/_healthz"` を含むスパンをフィルタリングしたす。これは通垞、ヘルスチェックリク゚ストに関連しおおり、䞀般的に非垞に「**ノむゞヌ**」です。 + +{{% exercise title="`3-dropping-spans` ディレクトリのセットアップ" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `3-dropping-spans` ディレクトリに倉曎し、`clear` コマンドを実行しおください。** + +`2-building-resilience` ディレクトリから `*.yaml` を `3-dropping-spans` にコピヌしたす。曎新埌のディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /exercise %}} + +次に、**filter processor** ず関連するパむプラむンを蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md new file mode 100644 index 0000000000..3aee4c6120 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md @@ -0,0 +1,120 @@ +--- +title: 4.1 Configuration +linkTitle: 4.1 Configuration +weight: 1 +--- + +このステップでは、`agent.yaml` を倉曎しお `attributes` プロセッサヌず `redaction` プロセッサヌを远加したす。これらのプロセッサヌは、スパン属性内の機密デヌタがログ出力や゚クスポヌトされる前に、適切に凊理されるようにするのに圹立ちたす。 + +これたでに、コン゜ヌルに衚瀺されるスパン属性の䞭に、個人情報や機密デヌタが含たれおいるこずに気づいたかもしれたせん。ここでは、これらの情報を効果的にフィルタリングしたり、線集 (redact) したりするために必芁なプロセッサヌを蚭定しおいきたす。 + +```text +Attributes: + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.account_password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + {"kind": "exporter", "data_type": "traces", "name": "debug"} +``` + +{{% exercise title="attributes プロセッサヌず redaction プロセッサヌを远加する" %}} + +**Agent タヌミナル** りィンドりに切り替えお、゚ディタヌで `agent.yaml` ファむルを開きたす。テレメトリヌデヌタのセキュリティずプラむバシヌを匷化するため、2 ぀のプロセッサヌを远加したす。 + +**1. `attributes` プロセッサヌの远加**: [**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) は、スパン属性 (タグ) の倀を曎新、削陀、ハッシュ化するこずで倉曎できたす。これは、機密情報を゚クスポヌト前に難読化する堎合に特に圹立ちたす。 + +このステップでは、以䞋のこずを行いたす。 + +1. `user.phone_number` 属性を、固定倀 `("UNKNOWN NUMBER")` に **曎新** したす。 +2. `user.email` 属性を **ハッシュ化** しお、元のメヌルアドレスが露出しないようにしたす。 +3. `user.password` 属性を **削陀** しお、スパンから完党に取り陀きたす。 + +```yaml + attributes/update: + actions: # Actions + - key: user.phone_number # Target key + action: update # Update action + value: "UNKNOWN NUMBER" # New value + - key: user.email # Target key + action: hash # Hash the email value + - key: user.password # Target key + action: delete # Delete the password + ``` + +**2. `redaction` プロセッサヌの远加**: [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) は、クレゞットカヌド番号やその他の個人を特定できる情報 (PII) などの事前定矩されたパタヌンに基づいお、スパン属性内の機密デヌタを怜出し、線集 (redact) したす。 + +このステップでは、以䞋を行いたす。 + +- すべおの属性が凊理されるように `allow_all_keys: true` を蚭定したす (`false` に蚭定した堎合は、明瀺的に蚱可されたキヌだけが保持されたす)。 + +- **Visa** および **MasterCard** のクレゞットカヌド番号を怜出し線集するための正芏衚珟を、`blocked_values` で定矩したす。 + +- `summary: debug` オプションを指定するず、線集凊理に関する詳现情報がデバッグ甚にログ出力されたす。 + +```yaml + redaction/redact: + allow_all_keys: true # If false, only allowed keys will be retained + blocked_values: # List of regex patterns to block + - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # Visa + - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # MasterCard + summary: debug # Show debug details about redaction +``` + +**`traces` パむプラむンを曎新する**: 䞡方のプロセッサヌを `traces` パむプラむンに統合したす。最初は redaction プロセッサヌをコメントアりトしおおくこずを忘れないでください (埌の別の挔習で有効化したす)。蚭定は以䞋のようになりたす。 + +```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + #- redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp +``` + +{{% /exercise %}} + +**[otelbin.io](https://www.otelbin.io/)** を䜿甚しお、゚ヌゞェントの蚭定を怜蚌したす。参考たでに、パむプラむンの `traces:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRML(memory_limiter
fa:fa-microchip):::processor + PRRD(resourcedetection
fa:fa-microchip):::processor + PRRS(resource
fa:fa-microchip
add_mode):::processor + PRUP(attributes
fa:fa-microchip
update):::processor + EXP1(otlphttp
fa:fa-upload):::exporter + EXP2(  debug  
fa:fa-upload):::exporter + EXP3(file
fa:fa-upload):::exporter + + %% Links + subID1:::sub-traces + subgraph " " + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRML + PRML --> PRUP + PRUP --> PRRD + PRRD --> PRRS + PRRS --> EXP2 + PRRS --> EXP3 + PRRS --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md new file mode 100644 index 0000000000..d4fbc7d2ce --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md @@ -0,0 +1,92 @@ +--- +title: 4.2 Attribute Processor のテスト +linkTitle: 4.2 Attribute Processor のテスト +weight: 2 +--- + +この挔習では、**Agent** によっお゚クスポヌトされる前のスパンデヌタから `user.account_password` を**削陀**し、`user.phone_number` **属性**を**曎新**し、`user.email` を**ハッシュ化**したす。 + +{{% exercise title="attributes processor をテストする" %}} + +**Gateway を起動する**: **Gateway タヌミナル**りィンドりで **Gateway** を起動したす。 + +```bash +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: **Agent タヌミナル**りィンドりで **Agent** を起動したす。 + +```bash +../otelcol --config=agent.yaml +``` + +**Load Generator を起動する**: **Loadgen タヌミナル**りィンドりで `loadgen` を起動したす。 + +```bash +../loadgen -count 1 +``` + +**デバッグ出力を確認する**: **Agent** ず **Gateway** の䞡方で、`user.account_password` が削陀され、`user.phone_number` ず `user.email` の䞡方が曎新されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="New Debug Output" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(UNKNOWN NUMBER) + -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287) + -> payment.amount: Double(51.71) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + ``` + +{{% /tab %}} +{{% tab title="Original Debug Output" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(95.22) + ``` + +{{% /tab %}} +{{% /tabs %}} + +**ファむル出力を確認する**: `jq` を䜿甚しお、`gateway-taces.out` 内で `user.account_password` が削陀され、`user.phone_number` ず `user.email` が曎新されおいるこずを怜蚌したす。 + +{{% tabs %}} +{{% tab title="Validate attribute changes" %}} + +```bash +jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.password" or .key == "user.phone_number" or .key == "user.email") | {key: .key, value: .value.stringValue}' ./gateway-traces.out +``` + +{{% /tabs %}} +{{% tab title="Output" %}} + +`user.account_password` が削陀され、`user.phone_number` ず `user.email` が曎新されおいるこずを確認したす。 + +```json +{ + "key": "user.phone_number", + "value": "UNKNOWN NUMBER" +} +{ + "key": "user.email", + "value": "62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287" +} +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止しおください。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md new file mode 100644 index 0000000000..96b4c83ec3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md @@ -0,0 +1,140 @@ +--- +title: 4.3 Redaction プロセッサヌのテスト +linkTitle: 4.3 Redaction プロセッサヌのテスト +weight: 3 +--- + +`redaction` プロセッサヌは、テレメトリヌデヌタから **蚱可** たたは **削陀** する属性ず倀を现かく制埡できたす。 + +この挔習では、**Agent** が゚クスポヌトする前のスパンデヌタの `user.visa` ず `user.mastercard` の倀を **リダクション** したす。 +{{% exercise title="redaction プロセッサヌのテスト" %}} + +**Gateway を起動する**: **Gateway terminal** りィンドりで **Gateway** を起動したす。 + +```bash +../otelcol --config=gateway.yaml +``` + +**`redaction/redact` プロセッサヌを有効にする**: **Agent terminal** りィンドりで `agent.yaml` を線集し、前の挔習で挿入した `#` を削陀したす。 + +```yaml + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp +``` + +**Agent を起動する**: **Agent terminal** りィンドりで **Agent** を起動したす。 + +```bash +../otelcol --config=agent.yaml +``` + +**Load Generator を起動する**: **Loadgen terminal** りィンドりで `loadgen` を起動したす。 + +```bash +../loadgen -count 1 +``` + +**デバッグ出力を確認する**: **Agent** ず **Gateway** の䞡方で `user.visa` ず `user.mastercard` の倀が曎新されおいるこずを確認したす。`user.amex` 属性の倀は `blocked_values` に䞀臎する正芏衚珟パタヌンが远加されおいないため、**リダクションされおいない** こずに泚意しおください。 + +{{% tabs %}} +{{% tab title="新しいデバッグ出力" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(UNKNOWN NUMBER) + -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287) + -> payment.amount: Double(69.71) + -> user.visa: Str(****) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(****) + -> redaction.masked.keys: Str(user.mastercard,user.visa) + -> redaction.masked.count: Int(2) + ``` + +{{% /tab %}} +{{% tab title="元のデバッグ出力" %}} + + ```text + -> user.name: Str(George Lucas) + -> user.phone_number: Str(+1555-867-5309) + -> user.email: Str(george@deathstar.email) + -> user.password: Str(LOTR>StarWars1-2-3) + -> user.visa: Str(4111 1111 1111 1111) + -> user.amex: Str(3782 822463 10005) + -> user.mastercard: Str(5555 5555 5555 4444) + -> payment.amount: Double(65.54) + ``` + +{{% /tab %}} +{{% /tabs %}} + +{{% notice note %}} +redaction プロセッサヌに `summary:debug` を含めるず、どの䞀臎したキヌの倀がリダクションされたかに぀いおの抂芁情報ず、マスクされた倀の数がデバッグ出力に含たれたす。 + +```text + -> redaction.masked.keys: Str(user.mastercard,user.visa) + -> redaction.masked.count: Int(2) + ``` + +{{% /notice %}} + +**ファむル出力を確認する**: `jq` を䜿甚しお、`gateway-traces.out` 内の `user.visa` ず `user.mastercard` が曎新されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="属性の倉曎を怜蚌する" %}} + +```bash +jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.visa" or .key == "user.mastercard" or .key == "user.amex") | {key: .key, value: .value.stringValue}' ./gateway-traces.out +``` + +{{% /tabs %}} +{{% tab title="出力" %}} + +`user.amex` は `blocked_values` に䞀臎する正芏衚珟パタヌンが远加されおいないため、リダクションされおいないこずに泚意しおください。 + +```json +{ + "key": "user.visa", + "value": "****" +} +{ + "key": "user.amex", + "value": "3782 822463 10005" +} +{ + "key": "user.mastercard", + "value": "****" +} +``` + +{{% /tab %}} +{{% /tabs %}} + +これらは `attributes` プロセッサヌず `redaction` プロセッサヌが機密デヌタを保護するために蚭定可胜な方法のほんの䞀䟋です。 + +{{% /exercise %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止しおください。 + + diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md new file mode 100644 index 0000000000..0e6a59ba27 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md @@ -0,0 +1,28 @@ +--- +title: 4. 機密デヌタの線集 +linkTitle: 4. 機密デヌタ +time: 10 minutes +weight: 6 +--- + +このセクションでは、OpenTelemetry Collector を蚭定しお特定のタグを削陀し、テレメトリスパンから機密デヌタを線集する方法を孊びたす。これは、クレゞットカヌド番号、個人デヌタ、その他セキュリティ関連の詳现など、凊理たたは送信される前に匿名化する必芁がある機密情報を保護するために重芁です。 + +OpenTelemetry Collector の䞻芁なプロセッサヌの蚭定方法を確認しおいきたす。具䜓的には次のずおりです。 + +- **[Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/README.md)**: 特定のスパン属性を倉曎たたは削陀したす。 +- [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/redactionprocessor/README.md): 機密デヌタが保存たたは送信される前にサニタむズされおいるこずを保蚌したす。 + +{{% exercise title="`4-sensitive-data` ディレクトリのセットアップ" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `4-sensitive-data` ディレクトリに移動し、`clear` コマンドを実行しおください。** + +`3-dropping-spans` ディレクトリから `*.yaml` を `4-sensitive-data` にコピヌしたす。曎新されたディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md new file mode 100644 index 0000000000..203d3f74cb --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md @@ -0,0 +1,113 @@ +--- +title: 5.1 Configuration +linkTitle: 5.1 Configuration +weight: 1 +--- + +{{% exercise title="`transform` プロセッサヌを远加する" %}} +**`transform` プロセッサヌを远加する**: **Gateway terminal** りィンドりに切り替えお `gateway.yaml` を線集し、以䞋の `transform` プロセッサヌを远加したす。 + +```yaml + transform/logs: # Processor Type/Name + log_statements: # Log Processing Statements + - context: resource # Log Context + statements: # List of attribute keys to keep + - keep_keys(attributes, ["com.splunk.sourcetype", "host.name", "otelcol.service.mode"]) +``` + +`-context: resource` キヌを䜿うこずで、ログの `resourceLog` 属性を察象ずしおいたす。 + +この蚭定により、関連するリ゜ヌス属性`com.splunk.sourcetype`、`host.name`、`otelcol.service.mode`のみが保持され、ログの効率が向䞊し、䞍芁なメタデヌタが削枛されたす。 + +**ログ重芁床マッピング甚のコンテキストブロックを远加する**: ログレコヌドの `severity_text` および `severity_number` フィヌルドを適切に蚭定するため、`log_statements` 内に `log` コンテキストブロックを远加したす。この蚭定では、ログ本文から `level` 倀を抜出しお `severity_text` にマッピングし、ログレベルに応じお察応する `severity_number` を割り圓おたす。 + +```yaml + - context: log # Log Context + statements: # Transform Statements Array + - set(cache, ParseJSON(body)) where IsMatch(body, "^\\{") # Parse JSON log body into a cache object + - flatten(cache, "") # Flatten nested JSON structure + - merge_maps(attributes, cache, "upsert") # Merge cache into attributes, updating existing keys + - set(severity_text, attributes["level"]) # Set severity_text from the "level" attribute + - set(severity_number, 1) where severity_text == "TRACE" # Map severity_text to severity_number + - set(severity_number, 5) where severity_text == "DEBUG" + - set(severity_number, 9) where severity_text == "INFO" + - set(severity_number, 13) where severity_text == "WARN" + - set(severity_number, 17) where severity_text == "ERROR" + - set(severity_number, 21) where severity_text == "FATAL" +``` + +`merge_maps` 関数は、2぀のマップ蟞曞を1぀に結合するために䜿甚したす。ここでは、`cache` オブゞェクトログ本文から解析された JSON デヌタを含むを `attributes` マップに結合したす。 + +- **パラメヌタ**: + - `attributes`: デヌタの結合先ずなるタヌゲットマップ。 + - `cache`: 解析された JSON デヌタを含む゜ヌスマップ。 + - `"upsert"`: このモヌドでは、`attributes` マップ内に既に存圚するキヌがあれば、その倀が `cache` の倀で曎新されたす。キヌが存圚しない堎合は新たに挿入されたす。 + +このステップは重芁です。なぜなら、ログ本文の関連フィヌルド䟋: `level`、`message` などがすべお `attributes` マップに远加され、埌続の凊理や゚クスポヌトで利甚できるようになるためです。 + +**䞻芁な倉換凊理のたずめ**: + +- **Parse JSON**: ログ本文から構造化デヌタを抜出したす。 +- **Flatten JSON**: ネストされた JSON オブゞェクトをフラットな構造に倉換したす。 +- **Merge Attributes**: 抜出されたデヌタをログ属性に統合したす。 +- **Map Severity Text**: ログの level 属性から severity_text を割り圓おたす。 +- **Assign Severity Numbers**: 重芁床レベルを暙準化された数倀に倉換したす。 + +> [!IMPORTANT] +> `transform` プロセッサヌは **1぀だけ** 持ち、その䞭に2぀のコンテキストブロック䞀方は `resource` 甚、もう䞀方は `log` 甚を含める必芁がありたす。 + +この蚭定により、ログの重芁床が正しく抜出、暙準化、構造化され、効率的な凊理が可胜になりたす。 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +すべおの JSON フィヌルドをトップレベル属性にマッピングするこの方法は、**OTTL のテストおよびデバッグ目的のみ** で䜿甚しおください。本番環境では高カヌディナリティを匕き起こしたす。 +{{% /notice %}} + +**`logs` パむプラむンを曎新する**: `logs:` パむプラむンに `transform/logs:` プロセッサヌを远加し、蚭定が以䞋のようになるようにしたす。 + +```yaml + logs: # Logs pipeline + receivers: + - otlp # OTLP receiver + processors: # Processors for logs + - memory_limiter + - resource/add_mode + - transform/logs + - batch + exporters: + - debug # Debug exporter + - file/logs +``` + +{{% /exercise %}} + +゚ヌゞェントの蚭定を [**https://otelbin.io**](https://otelbin.io/) で怜蚌しおください。参考たでに、パむプラむンの `logs:` セクションは以䞋のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(  otlp  
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(transform
fa:fa-microchip
logs):::processor + PRO5(batch
fa:fa-microchip):::processor + EXP1(file
fa:fa-upload
logs):::exporter + EXP2(  debug  
fa:fa-upload):::exporter + %% Links + subID1:::sub-logs + subgraph " " + subgraph subID1["`**Logs**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PRO3 + PRO3 --> PRO4 + PRO4 --> PRO5 + PRO5 --> EXP2 + PRO5 --> EXP1 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md new file mode 100644 index 0000000000..6510361df6 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md @@ -0,0 +1,29 @@ +--- +title: 5.2 環境のセットアップ +linkTitle: 5.2 環境のセットアップ +weight: 2 +--- + +{{% exercise title="transform テストのセットアップ" %}} + +**Gateway を起動する**: **Gateway terminal** で以䞋を実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動する**: **Agent terminal** で以䞋を実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Load Generator を起動する**: **Loadgen terminal** りィンドりで、**JSON を有効化** した状態で以䞋のコマンドを実行し、ロヌドゞェネレヌタヌを起動したす。 + +```bash { title="Log Generator" } +../loadgen -logs -json -count 5 +``` + +`loadgen` は JSON 圢匏で 5 行のログを `./quotes.log` に曞き蟌みたす。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md new file mode 100644 index 0000000000..b3de7b96d3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md @@ -0,0 +1,129 @@ +--- +title: 5.3 Test Transform Processor +linkTitle: 5.3 Test Transform Processor +weight: 3 +--- + +このテストでは、**Agent** によっお゚クスポヌトされる前に、`com.splunk/source` および `os.type` メタデヌタがログのリ゜ヌス属性から **削陀** されおいるこずを確認したす。さらに、このテストでは以䞋も確認したす。 + +1. ログ本文が解析され、重倧床情報が抜出されおいるこず。 + - `SeverityText` および `SeverityNumber` が `LogRecord` に蚭定されおいるこず。 +2. ログ本文の JSON フィヌルドがログの `attributes` に昇栌されおいるこず。 + +これにより、゚クスポヌト前に適切なメタデヌタのフィルタリング、重倧床のマッピング、構造化ログの゚ンリッチメントが行われるこずが保蚌されたす。 + +{{% exercise title="属性が削陀されおいるこずを確認する" %}} + +**デバッグ出力を確認する**: **Agent** ず **Gateway** の䞡方で、`com.splunk/source` および `os.type` が削陀されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="Gateway Debug Output" %}} + + ```text +Resource attributes: + -> com.splunk.sourcetype: Str(quotes) + -> host.name: Str(workshop-instance) + -> otelcol.service.mode: Str(agent) + ``` + +{{% /tab %}} +{{% tab title="Agent Debug Output" %}} + + ```text +Resource attributes: + -> com.splunk.source: Str(./quotes.log) + -> com.splunk.sourcetype: Str(quotes) + -> host.name: Str(workshop-instance) + -> os.type: Str(linux) + -> otelcol.service.mode: Str(agent) + ``` + +{{% /tab %}} +{{% /tabs %}} + +**Agent** ず **Gateway** の䞡方で、`LogRecord` の `SeverityText` および `SeverityNumber` がログ本文の重倧床 `level` を甚いお定矩されおいるこずを確認したす。本文の JSON フィヌルドが、トップレベルのログ `Attributes` ずしおアクセスできるこずを確認したす。 + +{{% tabs %}} +{{% tab title="Gateway Debug Output" %}} + +```text + +SeverityText: WARN +SeverityNumber: Warn(13) +Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"}) +Attributes: + -> log.file.path: Str(quotes.log) + -> level: Str(WARN) + -> message: Str(Your focus determines your reality.) + -> movie: Str(SW) + -> timestamp: Str(2025-03-07 11:17:26) + +``` + +{{% /tab %}} +{{% tab title="Agemt Debug Output" %}} + +```text + +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"}) +Attributes: + -> log.file.path: Str(quotes.log) + +``` + +{{% /tab %}} +{{% /tabs %}} + +**ファむル出力を確認する**: 新しい `gateway-logs.out` ファむルで、デヌタが倉換されおいるこずを確認したす。 + +{{% tabs %}} +{{% tab title="jq Query" %}} + +```bash +jq '[.resourceLogs[].scopeLogs[].logRecords[] | {severityText, severityNumber, body: .body.stringValue}]' gateway-logs.out +``` + +{{% /tabs %}} +{{% tab title="Example Output" %}} + +```json +[ + { + "severityText": "DEBUG", + "severityNumber": 5, + "body": "{\"level\":\"DEBUG\",\"message\":\"All we have to decide is what to do with the time that is given us.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "WARN", + "severityNumber": 13, + "body": "{\"level\":\"WARN\",\"message\":\"The Force will be with you. Always.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "ERROR", + "severityNumber": 17, + "body": "{\"level\":\"ERROR\",\"message\":\"One does not simply walk into Mordor.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + }, + { + "severityText": "DEBUG", + "severityNumber": 5, + "body": "{\"level\":\"DEBUG\",\"message\":\"Do or do not, there is no try.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}" + } +] +[ + { + "severityText": "ERROR", + "severityNumber": 17, + "body": "{\"level\":\"ERROR\",\"message\":\"There is some good in this world, and it's worth fighting for.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}" + } +] +``` + +{{% /tab %}} +{{% /tabs %}} + +{{% /exercise %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** プロセスを停止しおください。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md new file mode 100644 index 0000000000..d0636ca5c7 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md @@ -0,0 +1,39 @@ +--- +title: 5. Transform Data +linkTitle: 5. Transform Data +time: 10 minutes +weight: 7 +--- + +[**Transform Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md) を䜿うず、ログ、メトリクス、トレヌスなどのテレメトリヌデヌタがパむプラむンを流れる際に倉曎できたす。**OpenTelemetry Transformation Language (OTTL)** を䜿甚するこずで、アプリケヌションコヌドに觊れるこずなく、デヌタのフィルタリング、゚ンリッチメント、倉換をその堎で実行できたす。 + +この挔習では、`gateway.yaml` を曎新しお **Transform Processor** を組み蟌み、以䞋の凊理を行いたす。 + +- ログのリ゜ヌス属性を**フィルタリング**したす。 +- JSON 構造化ログデヌタを**パヌス**しお属性に倉換したす。 +- ログメッセヌゞ本文に基づいおログのシビリティレベルを**蚭定**したす。 + +これたでのログでは、`SeverityText` や `SeverityNumber` ずいったフィヌルドが未定矩になっおいるこずに気づいたかもしれたせん。これは `filelog` レシヌバヌの兞型的な挙動です。ただし、シビリティはログ本文の䞭に埋め蟌たれおいたす。䟋えば次のような圢匏です。 + +```text +SeverityText: +SeverityNumber: Unspecified(0) +Body: Str(2025-01-31 15:49:29 [WARN] - Do or do not, there is no try.) +``` + +ログには、ログ本文内に JSON ずしお゚ンコヌドされた構造化デヌタが含たれおいるこずがよくありたす。これらのフィヌルドを属性ずしお抜出するこずで、むンデックス䜜成、フィルタリング、ク゚リの効率が向䞊したす。䞋流システムで JSON を手䜜業でパヌスする代わりに、OTTL を䜿えばテレメトリヌパむプラむンレベルで自動的に倉換できたす。 + +{{% exercise title="Set up the `5-transform-data` directory" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりで `5-transform-data` ディレクトリに移動し、`clear` コマンドを実行しおください。** + +`4-sensitve-data` ディレクトリから `*.yaml` を `5-transform-data` にコピヌしたす。曎新埌のディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md new file mode 100644 index 0000000000..2751a3befb --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md @@ -0,0 +1,40 @@ +--- +title: 6.1 Routing Connector の蚭定 +linkTitle: 6.1 Routing の蚭定 +weight: 1 +--- + +この挔習では、`gateway.yaml` 内で **Routing Connector** を蚭定したす。Routing Connector はメトリクス、トレヌス、ログを任意の属性に基づいおルヌティングできたすが、ここでは `deployment.environment` 属性に基づくトレヌスのルヌティングに絞っお扱いたす任意の span / log / metric 属性を䜿甚可胜です。 + +{{% exercise title="Configure the routing connector" %}} + +**新しい `file` exporter を远加したす**: `routing` connector はルヌティング先ずしお耇数のタヌゲットを必芁ずしたす。**Gateway タヌミナル**で、`gateway.yaml` の `exporters` セクションに、デヌタが正しく振り分けられるよう、`file/traces/route1-regular` ず `file/traces/route2-security` の 2 ぀の新しい file exporter を䜜成したす。 + +```yaml + file/traces/route1-regular: # Exporter for regular traces + path: "./gateway-traces-route1-regular.out" # Path for saving trace data + append: false # Overwrite the file each time + file/traces/route2-security: # Exporter for security traces + path: "./gateway-traces-route2-security.out" # Path for saving trace data + append: false # Overwrite the file each time +``` + +`routing` connector を远加しお**ルヌティングを有効化**したす。OpenTelemetry の蚭定ファむルでは、`connectors` は receivers や processors ず同様に専甚のセクションを持っおいたす。 + +`#connectors:` セクションを芋぀けおコメントアりトを解陀したす。次に、`connectors:` セクションの䞋に以䞋を远加したす。 + +```yaml + routing: + default_pipelines: [traces/route1-regular] # Default pipeline if no rule matches + error_mode: ignore # Ignore errors in routing + table: # Define routing rules + # Routes spans to a target pipeline if the resourceSpan attribute matches the rule + - statement: route() where attributes["deployment.environment"] == "security-applications" + pipelines: [traces/route2-security] # Security target pipeline +``` + +{{% /exercise %}} + +蚭定ファむル内の default pipeline は Catch all ずしお機胜したす。これはルヌティングルヌルテヌブル内のどのルヌルにも䞀臎しないデヌタここでは spanに察するルヌティング先ずなりたす。このテヌブルでは、次のルヌル `["deployment.environment"] == "security-applications"` に䞀臎する span のルヌティング先ずなる pipeline を定矩しおいたす。 + +`routing` の蚭定が完了したら、次のステップではこれらのルヌティングルヌルを適甚するために `pipelines` を蚭定したす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md new file mode 100644 index 0000000000..ffe0383fe3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md @@ -0,0 +1,107 @@ +--- +title: 6.2 パむプラむンの構成 +linkTitle: 6.2 パむプラむンの構成 +weight: 2 +--- + +{{% exercise title="ルヌティングパむプラむンを接続する" %}} + +**元の `traces` パむプラむンをルヌティングを䜿甚するように曎新したす**: + +1. `routing` を有効にするため、元の `traces` パむプラむンを曎新しお `routing` を唯䞀の゚クスポヌタヌずしお䜿甚したす。これにより、すべおのスパンデヌタが評䟡のために **Routing Connector** を通過し、その埌接続されたパむプラむンぞ送られたす。たた、**すべおの** プロセッサヌを削陀し、空の配列`[]`に眮き換えたす。これらは `traces/route1-regular` および `traces/route2-security` パむプラむンで凊理され、それぞれのルヌトでカスタムの動䜜を実珟できるようになりたす。`traces:` の構成は以䞋のようになりたす: + + ```yaml + traces: # Traces pipeline + receivers: + - otlp # OTLP receiver + processors: [] # Processors for traces + exporters: + - routing + ``` + +**既存の `traces` パむプラむンの䞋に、`route1-regular` ず `route2-security` の䞡方のトレヌスパむプラむンを远加したす**: + +1. **Route1-regular パむプラむンを構成する**: このパむプラむンは、コネクタヌ内のルヌティングテヌブルで **䞀臎しなかった** すべおのスパンを凊理したす。 +これは唯䞀のレシヌバヌずしお `routing` を䜿甚しおおり、元のトレヌスパむプラむンから `connection` を通じおデヌタを受け取る点に泚目しおください。 + + ```yaml + traces/route1-regular: # Default pipeline for unmatched spans + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug Exporter + - file/traces/route1-regular # File Exporter for unmatched spans + ``` + +2. **route2-security パむプラむンを远加する**: このパむプラむンは、ルヌティングルヌル `"[deployment.environment"] == "security-applications"` に䞀臎するすべおのスパンを凊理したす。このパむプラむンもレシヌバヌずしお `routing` を䜿甚したす。このパむプラむンを `traces/route1-regular` の䞋に远加しおください。 + + ```yaml + traces/route2-security: # Default pipeline for unmatched spans + receivers: + - routing # Receive data from the routing connector + processors: + - memory_limiter # Memory Limiter Processor + - resource/add_mode # Adds collector mode metadata + - batch + exporters: + - debug # Debug exporter + - file/traces/route2-security # File exporter for unmatched spans + ``` + +{{% /exercise %}} + +゚ヌゞェント構成を **[otelbin.io](https://www.otelbin.io/)** で怜蚌したす。参考ずしお、パむプラむンの `traces:` セクションは以䞋のようになりたす: + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(   otlp   
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip):::processor + PRO6(batch
fa:fa-microchip):::processor + EXP1(  debug  
fa:fa-upload):::exporter + EXP2(  file  
fa:fa-upload
traces):::exporter + EXP3(  debug  
fa:fa-upload):::exporter + EXP4(  file  
fa:fa-upload
traces):::exporter + ROUTE1( routing 
fa:fa-route):::con-export + ROUTE2( routing 
fa:fa-route):::con-receive + ROUTE3( routing 
fa:fa-route):::con-receive + %% Links + subID1:::sub-traces + subID2:::sub-traces + subID3:::sub-traces + subgraph " " + direction LR + subgraph subID1["`**Traces**`"] + REC1 --> ROUTE1 + end + subgraph subID2["`**Traces/route2-security**`"] + ROUTE1 --> ROUTE2 + ROUTE2 --> PRO1 + PRO1 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + subgraph subID3["`**Traces/route1-regular**`"] + ROUTE1 --> ROUTE3 + ROUTE3 --> PRO2 + PRO2 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3; +``` diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md new file mode 100644 index 0000000000..0691a1f7f7 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md @@ -0,0 +1,77 @@ +--- +title: 6.3 Test Routing Connector +linkTitle: 6.3 Test Routing Connector +weight: 3 +--- + +{{% exercise title="Verify spans route to the security file" %}} + +このセクションでは、**Gateway** に蚭定した `routing` ルヌルをテストしたす。期埅される結果は、`loadgen` によっお生成された `span` のうち `"[deployment.environment"] == "security-applications"` ルヌルに䞀臎するものが、`gateway-traces-route2-security.out` ファむルに送信されるこずです。 + +**Gatewayを起動したす**: **Gateway terminal** りィンドりで **Gateway** を起動したす。 + +```bash +../otelcol --config gateway.yaml +``` + +**Agentを起動したす**: **Agent terminal** りィンドりで **Agent** を起動したす。 + +```bash +../otelcol --config agent.yaml +``` + +**通垞のSpanを送信したす**: **Loadgen terminal** りィンドりで `loadgen` を䜿甚しお通垞のスパンを送信したす。 + +```bash +../loadgen -count 1 +``` + +**Agent** ず **Gateway** の䞡方がデバッグ情報を衚瀺したす。Gatewayは新しい `gateway-traces-route1-regular.out` ファむルも生成したす。これは、通垞のスパンの送信先ずしお指定されたためです。 + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +`gateway-traces-route1-regular.out` を確認するず、`loadgen` によっお送信された `span` が含たれおいたす。たた、空の `gateway-traces-route2-security..out` ファむルも確認できたす。これは、ルヌティング蚭定が、䞀臎するスパンがただ凊理されおいない堎合でも出力ファむルを即座に䜜成するためです。 +{{% /notice %}} + +**Security Spanを送信したす**: **Loadgen terminal** りィンドりで `security` フラグを䜿甚しおセキュリティスパンを送信したす。 + +```bash +../loadgen -security -count 1 +``` + +再び、**Agent** ず **Gateway** の䞡方がデバッグ情報先ほど送信したスパンを含むを衚瀺するはずです。今回は、**Gateway** が `gateway-traces-route2-security.out` ファむルに行を曞き蟌みたす。このファむルは、`deployment.environment` リ゜ヌス属性が `"security-applications"` に䞀臎するスパン甚に指定されたものです。 + +{{% tabs %}} +{{% tab title="Validate resource attribute matches" %}} + +```bash +jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-route2-security.out +``` + +{{% /tabs %}} +{{% tab title="Output" %}} + +```json +{"spanId":"cb799e92e26d5782","deploymentEnvironment":"security-applications"} +``` + +{{% /tab %}} +{{% /tabs %}} + +このシナリオは耇数回繰り返すこずができ、各トレヌスは察応する出力ファむルに曞き蟌たれたす。 + +{{% /exercise %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止したす。 + +## Conclusion + +このセクションでは、異なるスパンを送信しお送信先を怜蚌するこずで、Gatewayにおけるルヌティングコネクタのテストに成功したした。 + +- **通垞のスパン** は `gateway-traces-route1-regular.out` に正しくルヌティングされたした。これにより、`deployment.environment` 属性が䞀臎しないスパンがデフォルトのパむプラむンに埓うこずが確認されたした。 + +- **セキュリティ関連のスパン** は `gateway-traces-route2-security.out` にルヌティングされたした。これにより、`"deployment.environment": "security-applications"` に基づくルヌティングルヌルが期埅どおりに動䜜するこずが実蚌されたした。 + +出力ファむルを怜査するこずで、OpenTelemetry Collectorが *スパンの属性を正しく評䟡し、適切な送信先にルヌティングする* こずを確認したした。これにより、ルヌティングルヌルが異なるナヌスケヌスに応じおテレメトリヌデヌタを効果的に分離し、振り分けられるこずが怜蚌されたす。 + +このアプロヌチを拡匵しお、異なる属性に基づいおスパン、メトリクス、ログをさらに分類するための远加のルヌティングルヌルを定矩するこずができたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md new file mode 100644 index 0000000000..c571b0c147 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md @@ -0,0 +1,27 @@ +--- +title: 6. デヌタのルヌティング +linkTitle: 6. デヌタのルヌティング +time: 10 minutes +weight: 8 +--- + +OpenTelemetry の [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) は、特定の条件に基づいおデヌタ`traces`、`metrics`、`logs`を異なるパむプラむンや宛先に振り分けるこずができる匷力な機胜です。これは、テレメトリヌデヌタのサブセットに察しお異なる凊理や゚クスポヌトロゞックを適甚したい堎合に特に圹立ちたす。 + +䟋えば、*production* のデヌタを 1 ぀の゚クスポヌタヌに送信し぀぀、*test* や *development* のデヌタを別の゚クスポヌタヌに振り分けるこずができたす。同様に、サヌビス名、環境、スパン名などの属性に基づいお特定のスパンをルヌティングし、カスタムの凊理や保存ロゞックを適甚するこずも可胜です。 + +{{% exercise title="`6-routing-data` ディレクトリのセットアップ" %}} + +> [!IMPORTANT] +> ***すべおの* タヌミナルりィンドりで `6-routing-data` ディレクトリに移動し、`clear` コマンドを実行しおください。** + +`5-transform-data` ディレクトリから `*.yaml` を `6-routing-data` にコピヌしたす。曎新されたディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +{{% /exercise %}} + +次に、routing connector ずそれぞれのパむプラむンを蚭定しおいきたす。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md new file mode 100644 index 0000000000..c7af716783 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md @@ -0,0 +1,93 @@ +--- +title: 7.1 Count Connector のテスト +linkTitle: 7.1 Count Connector のテスト +weight: 1 +--- + +{{% exercise title="Count Connector のテスト" %}} + +**Gateway を起動したす**: +**Gateway タヌミナル** りィンドりで次のコマンドを実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動したす**: +**Agent タヌミナル** りィンドりで次のコマンドを実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Loadgen で 12 行のログを送信したす**: +**Spans タヌミナル** りィンドりで 12 行のログを送信したす。これらは 2 ぀のむンタヌバルに分けお読み取られたす。次の `loadgen` コマンドを実行しおください。 + +```bash { title="Loadgen" } +../loadgen -logs -json -count 12 +``` + +**Agent** ず **Gateway** の䞡方がデバッグ情報を衚瀺し、デヌタを凊理しおいるこずを瀺したす。`loadgen` が完了するたで埅ちたす。 + +**メトリクスが生成されたこずを確認したす** +ログが凊理されるず、**Agent** はメトリクスを生成しお **Gateway** に転送し、**Gateway** はそれらを `gateway-metrics.out` に曞き蟌みたす。 + +`logs.full.count`、`logs.sw.count`、`logs.lotr.count`、`logs.error.count` のメトリクスが出力に含たれおいるかを確認するには、次の **jq** ク゚リを実行したす。 + +{{% tabs %}} +{{% tab title="jq query command" %}} + +```bash +jq '.resourceMetrics[].scopeMetrics[].metrics[] + | select(.name == "logs.full.count" or .name == "logs.sw.count" or .name == "logs.lotr.count" or .name == "logs.error.count") + | {name: .name, value: (.sum.dataPoints[0].asInt // "-")}' gateway-metrics.out +``` + +{{% /tab %}} +{{% tab title="jq example output" %}} + +```json +{ + "name": "logs.sw.count", + "value": "2" +} +{ + "name": "logs.lotr.count", + "value": "2" +} +{ + "name": "logs.full.count", + "value": "4" +} +{ + "name": "logs.error.count", + "value": "2" +} +{ + "name": "logs.error.count", + "value": "1" +} +{ + "name": "logs.sw.count", + "value": "2" +} +{ + "name": "logs.lotr.count", + "value": "6" +} +{ + "name": "logs.full.count", + "value": "8" +} +``` + +{{% /tab %}} +{{% /tabs %}} +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +泚: `logs.full.count` は通垞 `logs.sw.count` + `logs.lotr.count` ず等しくなりたすが、`logs.error.count` はランダムな数倀になりたす。 +{{% /notice %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止したす。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md new file mode 100644 index 0000000000..0647aa6c1d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md @@ -0,0 +1,159 @@ +--- +title: 7.2 Sum Connector でメトリクスを䜜成する +linkTitle: 7.2 Sum Connector +time: 10 minutes +weight: 2 +--- + +このセクションでは、[**Sum Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/sumconnector) がスパンから倀を抜出しおメトリクスに倉換する方法を芋おいきたす。 + +具䜓的には、ベヌススパンに含たれるクレゞットカヌドの請求額を利甚し、Sum Connector を掻甚しお請求額の合蚈をメトリクスずしお取埗したす。 + +このコネクタヌは、スパン、スパンむベント、メトリクス、デヌタポむント、ログレコヌドから属性倀を収集**sum**するために䜿甚できたす。各倀を個別にキャプチャし、メトリクスに倉換しお受け枡したす。ただし、これらのメトリクスずその属性を䜿っお蚈算やさらなる凊理を行うのは **バック゚ンド** の圹割です。 + +{{% exercise title="Sum Connector を远加する" %}} + +**Agent タヌミナル** りィンドりに切り替えお、゚ディタヌで `agent.yaml` ファむルを開きたす。 + +- **Sum Connector を远加する** +蚭定ファむルの connectors セクションに Sum Connector を远加し、メトリクスカりンタヌを定矩したす。 + +```yaml + sum: + spans: + user.card-charge: + source_attribute: payment.amount + conditions: + - attributes["payment.amount"] != "NULL" + attributes: + - key: user.name + +``` + +{{% /exercise %}} + +䞊蚘の䟋では、スパン内の `payment.amount` 属性をチェックしたす。有効な倀が含たれおいる堎合、**Sum** コネクタヌは `user.card-charge` ずいうメトリクスを生成し、`user.name` を属性ずしお含めたす。これにより、バック゚ンドは請求サむクルなどの長期間にわたるナヌザヌの請求合蚈額を远跡・衚瀺できるようになりたす。 + +以䞋のパむプラむン蚭定では、コネクタヌの゚クスポヌタヌを traces セクションに远加し、コネクタヌのレシヌバヌを metrics セクションに远加したす。 + +{{% exercise title="コネクタヌをパむプラむンに組み蟌む" %}} + +- **Count Connector をパむプラむンに蚭定する** + +```yaml + pipelines: + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp + - sum # Sum connector which aggregates payment.amount from spans and sends to metrics pipeline + metrics: + receivers: + - sum # Receives metrics from the sum exporter in the traces pipeline + - count # Receives count metric from logs count exporter in logs pipeline. + - otlp + #- hostmetrics # Host Metrics Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + logs: + receivers: + - otlp + - filelog/quotes + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - transform/logs # Transform logs processor + - batch + exporters: + - count # Count Connector that exports count as a metric to metrics pipeline. + - debug + - otlphttp +``` + +- **[otelbin.io](https://www.otelbin.io/)** を䜿っお Agent の蚭定を **怜蚌** したす。参考ずしお、パむプラむンの `traces` および `metrics:` セクションは次のような図になりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(otlp
fa:fa-download
):::receiver + REC3(otlp
fa:fa-download
):::receiver + PRO1(memory_limiter
fa:fa-microchip
):::processor + PRO2(memory_limiter
fa:fa-microchip
):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip
):::processor + PRO6(batch
fa:fa-microchip
):::processor + PRO7(resourcedetection
fa:fa-microchip
):::processor + PRO8(resourcedetection
fa:fa-microchip
):::processor + + PROA(attributes
fa:fa-microchip
redact):::processor + PROB(redaction
fa:fa-microchip
update):::processor + EXP1(  debug  
fa:fa-upload
):::exporter + EXP2(  file  
fa:fa-upload
):::exporter + EXP3(  debug  
fa:fa-upload
):::exporter + EXP4(  otlphttp  
fa:fa-upload
):::exporter + EXP5(  otlphttp  
fa:fa-upload
):::exporter + ROUTE1( sum 
fa:fa-route
):::con-export + ROUTE2( count 
fa:fa-route
):::con-receive + ROUTE3( sum 
fa:fa-route
):::con-receive + + %% Links + subgraph wrapper[" "] + direction LR + subgraph subID1["`**Traces**`"] + direction LR + REC1 --> PRO1 + PRO1 --> PROA + PROA --> PROB + PROB --> PRO7 + PRO7 --> PRO3 + PRO3 --> PRO5 + PRO5 --> EXP1 + PRO5 --> EXP2 + PRO5 --> EXP5 + PRO5 --> ROUTE1 + end + + subgraph subID2["`**Metrics**`"] + direction LR + ROUTE1 --> ROUTE3 + ROUTE3 --> PRO2 + ROUTE2 --> PRO2 + REC3 --> PRO2 + PRO2 --> PRO8 + PRO8 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end + class subID1 sub-traces + class subID2 sub-metrics + +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px,color:#34d399,stroke-dasharray: 3 3; +classDef sub-traces stroke:#fbbf24,stroke-width:1px,color:#fbbf24,stroke-dasharray: 3 3; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px,color:#38bdf8,stroke-dasharray: 3 3; +``` + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md new file mode 100644 index 0000000000..99b6e3b490 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md @@ -0,0 +1,67 @@ +--- +title: 7.3 Count Connector のテスト +linkTitle: 7.3 Sum Connector のテスト +weight: 3 +--- + +{{% exercise title="Sum Connector のテスト" %}} + +**Gateway を起動したす**: +**Gateway terminal** りィンドりで次のコマンドを実行したす。 + +```bash { title="Start the Gateway" } +../otelcol --config=gateway.yaml +``` + +**Agent を起動したす**: +**Agent terminal** りィンドりで次のコマンドを実行したす。 + +```bash { title="Start the Agent" } +../otelcol --config=agent.yaml +``` + +**Loadgen を起動したす**: +**Spans terminal** りィンドりで、次の `loadgen` コマンドを䜿甚しお 8 個のスパンを送信したす。 + +```bash { title="Loadgen" } +../loadgen -count 8 +``` + +**Agent** ず **Gateway** の䞡方がデバッグ情報を衚瀺し、デヌタを凊理しおいるこずを瀺したす。loadgen が完了するたでお埅ちください。 + +**メトリクスを確認したす**: +スパンの凊理䞭に、**Agent** はメトリクスを生成し、**Gateway** に枡しおいたす。**Gateway** はそれらを `gateway-metrics.out` に曞き蟌んでいたす。 + +メトリクス出力に `user.card-charge` が存圚するこずを確認し、それぞれが `user.name` 属性を持っおいるこずを怜蚌するために、次の jq ク゚リを実行したす。 + +{{% tabs %}} +{{% tab title="jq query command" %}} + +```bash + +jq -r '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "user.card-charge") | .sum.dataPoints[] | "\(.attributes[] | select(.key == "user.name").value.stringValue)\t\(.asDouble)"' gateway-metrics.out | while IFS=$'\t' read -r name charge; do + printf "%-20s %s\n" "$name" "$charge" +done +``` + +{{% /tab %}} +{{% tab title="jq example output" %}} + +```text +George Lucas 67.49 +Frodo Baggins 87.14 +Thorin Oakenshield 90.98 +Luke Skywalker 51.37 +Luke Skywalker 65.56 +Thorin Oakenshield 67.5 +Thorin Oakenshield 66.66 +Peter Jackson 94.39 +``` + +{{% /tab %}} +{{% /tabs %}} + +> [!IMPORTANT] +> それぞれのタヌミナルで `Ctrl-C` を抌しお、**Agent** ず **Gateway** のプロセスを停止したす。 + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md new file mode 100644 index 0000000000..a26ae0a7b6 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md @@ -0,0 +1,192 @@ +--- +title: 7. Count Connector でメトリクスを䜜成する +linkTitle: 7. Count & Sum Connector +time: 10 minutes +weight: 9 +--- +このセクションでは、[**Count Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector) を䜿甚しお、ログから属性倀を抜出し、意味のあるメトリクスに倉換する方法を探りたす。 + +具䜓的には、Count Connector を䜿甚しおログに出珟する「Star Wars」ず「Lord of the Rings」の匕甚回数を远跡し、蚈枬可胜なデヌタポむントに倉換したす。 + +{{% exercise title="`7-sum-count` ディレクトリのセットアップ" %}} + +> [!IMPORTANT] +> **_すべおの_ タヌミナルりィンドりを `7-sum-count` ディレクトリに切り替え、`clear` コマンドを実行しおください。** + +`6-routing-data` ディレクトリから `*.yaml` を `7-sum-count` にコピヌしたす。曎新埌のディレクトリ構造は次のようになりたす。 + +```text { title="Updated Directory Structure" } +. +├── agent.yaml +└── gateway.yaml +``` + +- **agent.yaml を曎新** しお、ログを読み取る頻床を倉曎したす。 +`agent.yaml` 内の `filelog/quotes` レシヌバヌを芋぀けお、`poll_interval` 属性を远加しおください。 + +```yaml + filelog/quotes: # Receiver Type/Name + poll_interval: 10s # Only read every ten seconds +``` + +{{% /exercise %}} + +遅延を蚭ける理由は、OpenTelemetry Collector の Count Connector が各凊理間隔内のログのみをカりントするためです。぀たり、デヌタが読み取られるたびに、次の間隔のためにカりントがれロにリセットされたす。デフォルトの `Filelog reciever` の間隔である 200ms では、loadgen が曞き蟌むすべおの行を読み取り、カりントが 1 になっおしたいたす。この間隔を蚭定するこずで、カりント察象の゚ントリが耇数になるこずを保蚌したす。 + +Collector は、以䞋に瀺すように条件を省略するこずで、各読み取り間隔のランニングカりントを維持できたす。ただし、ランニングカりントはより長い期間にわたっお远跡できるバック゚ンドに任せるのがベストプラクティスです。 + +{{% exercise title="Count Connector の远加" %}} + +- **Count Connector の远加** + +蚭定の connectors セクションに Count Connector を含め、䜿甚するメトリクスカりンタヌを定矩したす。 + +```yaml +connectors: + count: + logs: + logs.full.count: + description: "Running count of all logs read in interval" + logs.sw.count: + description: "StarWarsCount" + conditions: + - attributes["movie"] == "SW" + logs.lotr.count: + description: "LOTRCount" + conditions: + - attributes["movie"] == "LOTR" + logs.error.count: + description: "ErrorCount" + conditions: + - attributes["level"] == "ERROR" +``` + +- **メトリクスカりンタヌの説明** + + - `logs.full.count`: 各読み取り間隔で凊理されたログの総数を远跡したす。 + このメトリクスにはフィルタリング条件がないため、システムを通過するすべおのログがカりントに含たれたす。 + - `logs.sw.count` Star Wars 映画の匕甚を含むログをカりントしたす。 + - `logs.lotr.count`: Lord of the Rings 映画の匕甚を含むログをカりントしたす。 + - `logs.error.count`: 読み取り間隔内で重倧床レベルが ERROR のログをカりントするこずで、珟実䞖界のシナリオを衚珟したす。 + +- **パむプラむンで Count Connector を構成する** +以䞋のパむプラむン構成では、コネクタヌの゚クスポヌタヌが `logs` セクションに远加され、コネクタヌのレシヌバヌが `metrics` セクションに远加されおいたす。 + +```yaml + pipelines: + traces: + receivers: + - otlp + processors: + - memory_limiter + - attributes/update # Update, hash, and remove attributes + - redaction/redact # Redact sensitive fields using regex + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - file + - otlphttp + metrics: + receivers: + - count # Count Connector that receives count metric from logs count exporter in logs pipeline. + - otlp + #- hostmetrics # Host Metrics Receiver + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - batch + exporters: + - debug + - otlphttp + logs: + receivers: + - otlp + - filelog/quotes + processors: + - memory_limiter + - resourcedetection + - resource/add_mode + - transform/logs # Transform logs processor + - batch + exporters: + - count # Count Connector that exports count as a metric to metrics pipeline. + - debug + - otlphttp +``` + +{{% /exercise %}} + +ログは属性に基づいおカりントしたす。ログデヌタが属性ではなくログ本文に栌玍されおいる堎合は、パむプラむンで `Transform` プロセッサヌを䜿甚しおキヌ/倀のペアを抜出し、属性ずしお远加する必芁がありたす。 + +このワヌクショップでは、`05-transform-data` セクションですでに `merge_maps(attributes, cache, "upsert")` を远加しおいたす。これにより、凊理に必芁なすべおの関連デヌタがログ属性に含たれるこずが保蚌されたす。 + +属性を䜜成するフィヌルドを遞択する際は泚意が必芁です。すべおのフィヌルドを無差別に远加するこずは、本番環境では䞀般的に望たしくありたせん。代わりに、䞍芁なデヌタの乱雑さを避けるため、本圓に必芁なフィヌルドのみを遞択しおください。 + +{{% exercise title="゚ヌゞェント蚭定の怜蚌" %}} + +- **[otelbin.io](https://www.otelbin.io/)** を䜿甚しお゚ヌゞェント蚭定を **怜蚌** しおください。参考たでに、パむプラむンの `logs` および `metrics:` セクションは次のようになりたす。 + +```mermaid +%%{init:{"fontFamily":"monospace"}}%% +graph LR + %% Nodes + REC1(otlp
fa:fa-download):::receiver + REC2(filelog
fa:fa-download
quotes):::receiver + REC3(otlp
fa:fa-download):::receiver + PRO1(memory_limiter
fa:fa-microchip):::processor + PRO2(memory_limiter
fa:fa-microchip):::processor + PRO3(resource
fa:fa-microchip
add_mode):::processor + PRO4(resource
fa:fa-microchip
add_mode):::processor + PRO5(batch
fa:fa-microchip):::processor + PRO6(batch
fa:fa-microchip):::processor + PRO7(resourcedetection
fa:fa-microchip):::processor + PRO8(resourcedetection
fa:fa-microchip):::processor + PRO9(transfrom
fa:fa-microchip
logs):::processor + EXP1(  debug  
fa:fa-upload):::exporter + EXP2(  otlphttp  
fa:fa-upload):::exporter + EXP3(  debug  
fa:fa-upload):::exporter + EXP4(  otlphttp  
fa:fa-upload):::exporter + ROUTE1( count 
fa:fa-route):::con-export + ROUTE2( count 
fa:fa-route):::con-receive + + %% Links + subID1:::sub-logs + subID2:::sub-metrics + subgraph " " + direction LR + subgraph subID1[**Logs**] + direction LR + REC1 --> PRO1 + REC2 --> PRO1 + PRO1 --> PRO7 + PRO7 --> PRO3 + PRO3 --> PRO9 + PRO9 --> PRO5 + PRO5 --> ROUTE1 + PRO5 --> EXP1 + PRO5 --> EXP2 + end + + subgraph subID2["`**Metrics**`"] + direction LR + ROUTE1 --> ROUTE2 + ROUTE2 --> PRO2 + REC3 --> PRO2 + PRO2 --> PRO8 + PRO8 --> PRO4 + PRO4 --> PRO6 + PRO6 --> EXP3 + PRO6 --> EXP4 + end + end +classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff; +classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff; +classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff; +classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3; +classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3; +``` + +{{% /exercise %}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md new file mode 100644 index 0000000000..fc0ba8599e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md @@ -0,0 +1,7 @@ +--- +title: 8. たずめ +linkTitle: 8. たずめ +weight: 10 +--- + +![Well done](../images/welldone.png) diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md new file mode 100644 index 0000000000..bf2bb0a297 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md @@ -0,0 +1,35 @@ +--- +title: Advanced OpenTelemetry Collector +description: OpenTelemetry Collector の蚭定をれロから構築する緎習を行い、いく぀かの高床な蚭定シナリオを通しお孊習したす。 +weight: 2 +type: chapter +authors: ["Robert Castley", "Charity Anderson", "Pieter Hagen", "Geoff Higginbottom"] +time: 75 minutes +--- + +このワヌクショップの目的は、OpenTelemetry Collector の蚭定ファむルの䜜成ず倉曎に自信を持おるようにするこずです。最小限の `agent.yaml` ず `gateway.yaml` ファむルから始めお、段階的に拡匵しながら、いく぀かの高床な実践的シナリオに察応できるように構築しおいきたす。 + +このワヌクショップで重芖するポむントは、テレメトリヌデヌタをサヌドパヌティベンダヌのバック゚ンドに送信するのではなく、ロヌカルに保存するように OpenTelemetry Collector を蚭定する方法を孊ぶこずです。このアプロヌチはデバッグやトラブルシュヌティングを容易にするだけでなく、本番システムぞのデヌタ送信を避けたいテストや開発環境にも最適です。 + +このワヌクショップを最倧限に掻甚するためには、以䞋が必芁です。 + +- OpenTelemetry Collector ずその蚭定ファむル構造に関する基本的な理解。 +- YAML ファむルの線集に関する習熟。 + +このワヌクショップのすべおの内容は、ロヌカルで実行できるように蚭蚈されおおり、ハンズオン圢匏でアクセスしやすい孊習䜓隓を提䟛したす。それでは、構築を始めおいきたしょう + +## Workshop Overview + +このワヌクショップでは、以䞋のトピックを取り䞊げたす。 + +- **agent ず gateway をロヌカルにセットアップする**: メトリクス、トレヌス、ログが agent を経由しお gateway に送られるこずをテストしたす。 +- **agent のレゞリ゚ンス匷化**: フォヌルトトレランスのための基本的な蚭定。 +- **プロセッサヌの蚭定**: + - 特定のスパン䟋ヘルスチェックを砎棄するこずでノむズをフィルタリングしたす。 + - 䞍芁なタグを削陀し、機密デヌタを取り扱いたす。 + - ゚クスポヌト前に、パむプラむン内で OTTLOpenTelemetry Transformation Languageを䜿っおデヌタを倉換したす。 +- **コネクタヌの蚭定**: + - 受信した倀に基づいお、異なる゚ンドポむントぞデヌタをルヌティングしたす。 + + +このワヌクショップを終える頃には、さたざたな実践的なナヌスケヌスに察応した OpenTelemetry Collector の蚭定に慣れおいるはずです。 diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md new file mode 100644 index 0000000000..ca373dc91f --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md @@ -0,0 +1,175 @@ +--- +title: 前提条件 +weight: 2.1 +archetype: chapter +time: 5 minutes +--- + +## 前提条件 + +- `vi`、`vim`、`nano`、たたはお奜みのテキスト゚ディタヌを䜿甚しおYAMLファむルを線集できるこず。 +- サポヌトされおいる環境: + - 提䟛されるSplunk Workshop Instance掚奚。`ssh` アクセスのため、ポヌト `2222` ぞの送信アクセスが必芁です。 + - Apple Mac (Apple Silicon)。`jq` のむンストヌルが必芁です - [**https://jqlang.org/download/**](https://jqlang.org/download/) + +{{% exercise title="ワヌクショップ甚ディレクトリの䜜成" %}} + +{{< step "初期セットアップ" "1" >}} + +ご利甚の環境で新しいディレクトリを䜜成し、そのディレクトリに移動したす: + +``` bash +mkdir advanced-otel-workshop && \ +cd advanced-otel-workshop +``` + +このディレクトリは、ワヌクショップの残りの郚分で `[WORKSHOP]` ずしお参照したす。 + +{{% notice title="既存のOpenTelemetry Collectorを削陀する" style="warning" %}} +Splunk IMワヌクショップを完了しおいる堎合、続行する前にKubernetes䞊で動䜜しおいるcollectorが削陀されおいるこずを確認しおください。これは以䞋のコマンドを実行するこずで実斜できたす: + +``` bash +helm delete splunk-otel-collector +``` + +その堎合のEC2むンスタンスでは、本ワヌクショップに干枉する可胜性のあるサヌビスが動䜜しおいる堎合があるため、以䞋のコマンドを実行しお、それらが存圚する堎合は確実に停止させおください: + +``` bash +kubectl delete ~/workshop/apm/deployment.yaml +``` + +{{% /notice %}} +{{< /step >}} + +{{< step "ワヌクショップのバむナリをダりンロヌド" "2" >}} + +`[WORKSHOP]` ディレクトリに移動し、OpenTelemetry Collector、Load Generatorのバむナリ、およびセットアップスクリプトをダりンロヌドしたす: + +{{% tabs %}} +{{% tab title="Splunk Workshop Instance" %}} + +```bash +curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_linux_amd64 -o otelcol && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-linux-amd64 -o loadgen && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \ +chmod +x setup-workshop.sh +``` + +{{% /tab %}} +{{% tab title="Apple Silicon" %}} + +```bash +curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_darwin_arm64 -o otelcol && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-darwin-arm64 -o loadgen && \ +curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \ +chmod +x setup-workshop.sh +``` + +{{% /tab %}} +{{% /tabs %}} + +{{< /step >}} + +{{< step "セットアップを実行する" "3" >}} +`setup-workshop.sh` スクリプトを実行したす。このスクリプトは正しい暩限を蚭定するずずもに、**Agent** および **Gateway** の初期蚭定を䜜成したす: + +{{% tabs %}} +{{% tab title="Setup Workshop" %}} + +```bash +./setup-workshop.sh +``` + +{{% /tab %}} +{{% tab title="Verify Setup" %}} + +```text +███████╗██████╗ ██╗ ██╗ ██╗███╗ ██╗██╗ ██╗ ██╗ +██╔════╝██╔══██╗██║ ██║ ██║████╗ ██║██║ ██╔╝ ╚██╗ +███████╗██████╔╝██║ ██║ ██║██╔██╗ ██║█████╔╝ ╚██╗ +╚════██║██╔═══╝ ██║ ██║ ██║██║╚██╗██║██╔═██╗ ██╔╝ +███████║██║ ███████╗╚██████╔╝██║ ╚████║██║ ██╗ ██╔╝ +╚══════╝╚═╝ ╚══════╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═╝ + +Welcome to the Splunk Advanced OpenTelemetry Workshop! +====================================================== + +macOS detected. Removing quarantine attributes... +otelcol version v0.126.0 +Usage: loadgen [OPTIONS] +Options: + -base Send base traces (enabled by default) + -health Send health traces + -security Send security traces + -logs Enable logging of random quotes to quotes.log + -json Output logs in JSON format (only applicable with -logs) + -count Number of traces or logs to send (default: infinite) + -h, --help Display this help message + +Example: + loadgen -health -security -count 10 Send 10 health and security traces + loadgen -logs -json -count 5 Write 5 random quotes in JSON format to quotes.log +Creating workshop directories... +✓ Created subdirectories: + ├── 1-agent-gateway + ├── 2-building-resilience + ├── 3-dropping-spans + ├── 4-sensitive-data + ├── 5-transform-data + ├── 6-routing-data + └── 7-sum-count + +Creating configuration files for 1-agent-gateway... +Creating OpenTelemetry Collector agent configuration file: 1-agent-gateway/agent.yaml +✓ Configuration file created successfully: 1-agent-gateway/agent.yaml +✓ File size: 4355 bytes + +Creating OpenTelemetry Collector gateway configuration file: 1-agent-gateway/gateway.yaml +✓ Configuration file created successfully: 1-agent-gateway/gateway.yaml +✓ File size: 3376 bytes + +✓ Completed configuration files for 1-agent-gateway + +Creating configuration files for 2-building-resilience... +Creating OpenTelemetry Collector agent configuration file: 2-building-resilience/agent.yaml +✓ Configuration file created successfully: 2-building-resilience/agent.yaml +✓ File size: 4355 bytes + +Creating OpenTelemetry Collector gateway configuration file: 2-building-resilience/gateway.yaml +✓ Configuration file created successfully: 2-building-resilience/gateway.yaml +✓ File size: 3376 bytes + +✓ Completed configuration files for 2-building-resilience + +Workshop environment setup complete! +Configuration files created in the following directories: + 1-agent-gateway/ + ├── agent.yaml + └── gateway.yaml + 2-building-resilience/ + ├── agent.yaml + └── gateway.yaml +``` + +{{% /tab %}} +{{% /tabs %}} + +```text { title="Initial Directory Structure" } +[WORKSHOP] +├── 1-agent-gateway +├── 2-building-resilience +├── 3-dropping-spans +├── 4-sensitive-data +├── 5-transform-data +├── 6-routing-data +├── 7-sum-count +├── loadgen +├── otelcol +└── setup-workshop.sh +``` + +{{< /step >}} + +{{% /exercise %}} + +{{< checkpoint "ワヌクショップ環境の準備が完了したした — **第1ç« : Agent Configuration** ぞ進みたしょう。" >}} diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md new file mode 100644 index 0000000000..ea18a89f82 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md @@ -0,0 +1,9 @@ +--- +title: OpenTelemetry Collector ワヌクショップ +weight: 3 +time: 2 hours 15 minutes +description: OpenTelemetry Collector を 2 郚構成で深く掘り䞋げたす。前半では receiver / processor / exporter の基瀎を孊び、埌半では実践的なシナリオを通じお agent および gateway の構成をれロから構築したす。 +aliases: + - /ninja-workshops/3-opentelemetry-collector-workshops/ +layout: "hero" +--- diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md new file mode 100644 index 0000000000..e2d315d99a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md @@ -0,0 +1,42 @@ +--- +title: Dashboard Workshop +description: Splunk Observability Cloud でカスタムダッシュボヌドを構築したす — チャヌト、フィルタヌ、分析関数、SignalFlow 数匏。 +weight: 7 +archetype: chapter +authors: ["Pieter Hagen"] +time: 45 minutes +draft: false +aliases: + - /ninja-workshops/7-dashboards-detectors/ +--- +Splunk Observability Cloud の **Dashboards** に関するワヌクショップぞようこそ。このセッションでは、掞察に富んだビゞュアラむれヌションの構築をハンズオンで䜓隓しおいただけたす。 + + + +Splunk Observability Suite で利甚可胜な既存のデモデヌタを䜿っお䜜業を進めたす。アクセス可胜な **trial** たたは **production** の Splunk Observability 組織であれば、どれでも䜿っおこのワヌクショップを進めるこずができたす。 + +## このワヌクショップで孊ぶこず + +### Dashboards + +ワヌクショップの前半では、ダッシュボヌドずチャヌトに焊点を圓おたす。 + +* ダッシュボヌドの理解ずチャヌトの圹割 +* 既存チャヌトの線集ず新芏チャヌトの䜜成 +* フィルタヌの適甚ず分析関数の利甚 +* 数匏の構築ずカスタマむズ +* 再利甚するためのダッシュボヌドぞのチャヌト保存 +* 高床なチャヌト䜜成のための SignalFlow 入門 + + diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md new file mode 100644 index 0000000000..e7ae68282a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md @@ -0,0 +1,27 @@ +--- +title: サンプルデヌタの堎所を確認する +linkTitle: 1.01. Sample Data +weight: 1.01 +time: 10 minutes +--- + +## 1. サンプルデヌタを探玢する + +利甚可胜なダッシュボヌドの䞀芧から、**Sample Data (2)** ずいう名前のグルヌプを探したす。 + +このグルヌプには、サンプルメトリクスを䜿甚しお構築された可芖化を玹介するダッシュボヌドが含たれおいたす。これらのダッシュボヌドを通じお、Splunk Observability のチャヌトやダッシュボヌドでさたざたなデヌタをどのように衚珟できるかを把握できたす。 + +![Sample Data](../../images/sample-data.png) + +--- + +**Sample Data** ダッシュボヌドグルヌプをクリックしお展開し、**Sample Charts (3)** ダッシュボヌドを遞択したす。 + +このダッシュボヌドでは、Splunk Observability で利甚できるさたざたなチャヌトタむプ、スタむル、フォヌマットオプションを玹介しおいたす。ダッシュボヌドがいかに柔軟でカスタマむズ可胜かを䜓感するのに最適です。 + +サンプルデヌタは 10 分呚期で動䜜し、時間の経過ずずもに異なるパタヌンや挙動を生成したす。 +これらの倉化を実際に確認するには、ダッシュボヌド右䞊の時間範囲を **Last 15 minutes** に倉曎するか、より広い範囲で確認したい堎合は **Last 1 hour** を遞択しおください。これにより、デヌタが曎新され、さたざたな状態を呚期的に倉化しおいく様子を芳察できたす。 + +少し時間を取っおこのダッシュボヌド内のチャヌトを探玢しおみおください。それぞれが、サンプルデヌタをどのように可芖化できるかに぀いお異なる芖点を提䟛しおいたす。 + +![Sample Charts](../../images/sample-charts.png) diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md new file mode 100644 index 0000000000..027df61d54 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md @@ -0,0 +1,42 @@ +--- +title: Exploring Charts +linkTitle: 1.02. Exploring Charts +weight: 1.02 +--- +このセクションでは、Splunk Observability におけるチャヌトの構築方法ず衚瀺方法を確認しおいきたす。既存のチャヌトを芳察し操䜜するこずで、チャヌト゚ディタの動䜜の仕組みデヌタ゜ヌスの遞択方法、ビゞュアルオプションの構成方法、各皮蚭定が衚瀺にどう圱響するかを䜓感できたす。 + +## 1. チャヌトを遞択する + +たずは **SAMPLE CHARTS** ダッシュボヌドを開いた状態にし、ダッシュボヌド右䞊の時間範囲を **-5M** (Last 5 Minutes) に戻すか、**reset to default** を遞択しおください。 + +**Latency histogram** チャヌトを芋぀け、チャヌト右䞊の **䞉点リヌダヌ** (...) **(1)** をクリックしたす。メニュヌから **Open (3)** を遞択したす。あるいは、チャヌトタむトル**Latency histogram****(2)** を盎接クリックしお開くこずもできたす。 + +![Sample Charts](../../images/latency-histogram-open.png) + +--- +チャヌト゚ディタが開くず、Latency histogram チャヌトの構成蚭定が衚瀺されたす。 + +チャヌト゚ディタは、デヌタの可芖化方法を制埡するための堎所です。チャヌトタむプの倉曎、倉換関数の適甚、時間蚭定の調敎、その他のビゞュアル関連やデヌタ関連のオプションを、目的に合わせおカスタマむズできたす。 + +![Latency Histogram](../../images/latency-histogram.png) + +--- + +**Plot Editor (1)** タブの **Signal (2)** セクションには、珟圚䜿甚されおいるメトリクス `demo.trans.latency` **(3)** が衚瀺されおいたす。このシグナルは、チャヌトでプロットされおいるレむテンシヌデヌタを衚しおいたす。この゚リアでは、シグナルを線集したり、比范や情報の远加のために別のシグナルを远加したりできたす。 + +チャヌトには、耇数の **Line** プロットが衚瀺されおいるこずがわかりたす。`18 ts` **(4)** ずいうラベルは、チャヌトが珟圚 **18 個の個別のメトリクス時系列** をプロットしおいるこずを瀺しおいたす。 +![Plot Editor](../../images/plot-editor.png) + +さたざたな可芖化スタむルを詊すために、゚ディタにある各チャヌトタむプのアむコンをクリックしおみおください。各アむコンにマりスカヌ゜ルを合わせるず名前が衚瀺され、それぞれのタむプが䜕を衚しおいるかを把握できたす。 + +![Chart Types](../../images/chartbartypes.png) + +たずえば、**Heat Map** アむコンをクリックしお、同じデヌタが別の圢匏でどのように衚珟されるかを確認しおみたしょう。 + +![Change to Heatmap](../../images/change-to-heatmap.png) + +{{% notice title="Note" style="info" %}} +メトリクスはさたざたなチャヌトタむプで可芖化できたす。匷調したいむンサむトを最もよく衚すものを遞んでください。 + +利甚可胜なチャヌトタむプずその䜿い分けの詳现に぀いおは、[Choosing a chart type.](https://docs.splunk.com/Observability/data-visualization/charts/chart-types.html#chart-types) を参照しおください。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md new file mode 100644 index 0000000000..0a75222958 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md @@ -0,0 +1,45 @@ +--- +title: Editing Charts +linkTitle: 1.04. Editing Charts +weight: 1.04 +--- +このセクションでは、既存のチャヌトを線集するこずで、チャヌトがどのように構成されおいるかを探っおいきたす。これは、チャヌト゚ディタヌを実際に操䜜しながら、チャヌトの蚭定、デヌタ゜ヌス、可芖化オプションがどのように組み合わさっおいるかを理解するうえで最適な方法です。 + +--- +**Latency histogram** チャヌトをチャヌト゚ディタヌで開いた状態で、ワヌクショップ甚の蚭定を始めたしょう。 + +**visualization** ペむンの **Line chart** タむプアむコン **(1)** をクリックしお、チャヌトタむプを倉曎したす。デヌタが折れ線プロットずしお衚瀺されるようになりたす。 + +![Line Chart](../../images/change-to-line.png) + +## 2. チャヌトの時間りィンドりの倉曎 + +チャヌトの時間範囲を調敎しお、より過去のデヌタを衚瀺できたす。これを行うには、チャヌト゚ディタヌ右䞊隅の **Time (1)** ドロップダりンをクリックし、**Past 15 minutes (2)** を遞択したす。 + +これにより時間りィンドりが拡倧され、より長い期間にわたるメトリクスの傟向を確認できるようになりたす。 + +![Line Chart](../../images/time_window.png) + +## 3. デヌタテヌブルの探玢 + +チャヌト゚ディタヌの **Data Table (1)** タブをクリックしたす。 + +**Data Table** では、チャヌトを支えおいるメトリクス時系列の内郚を確認できたす。 + +![Data Table](../../images/data-table.png) + +テヌブルの各行は1぀の時系列を衚し、各列はその時系列に関連付けられたディメンションを瀺したす。メトリクス `demo.trans.latency` には、以䞋のディメンションが衚瀺されたす: + +- `demo_datacenter` **(2)** +- `demo_customer` **(3)** +- `demo_host` **(4)** + +**`demo_datacenter`** 列には、2぀のデヌタセンタヌ: **Paris (5)** ず **Tokyo (6)** があるこずがわかりたす。 +それぞれに耇数の時系列が関連付けられおいたす。 + +カヌ゜ルをチャヌト䞊で時間軞方向に氎平に移動させるず、**Data Table** はリアルタむムで曎新され、珟圚の時点の倀が反映されたす。チャヌト内の特定の線をクリックするず、その時系列がテヌブル䞊にピン留めされ、固定倀が衚瀺されたす。これは **pinned value (7)** で瀺されたす。 + +--- +準備ができたら、**Plot editor (8)** タブをクリックしおデヌタテヌブルを閉じたす。 + +次に、埌で再利甚できるように、このチャヌトをダッシュボヌドに保存したしょう diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md new file mode 100644 index 0000000000..ede2c4ce68 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md @@ -0,0 +1,67 @@ +--- +title: チャヌトずダッシュボヌドの保存 +linkTitle: 1.04. チャヌトの保存 +weight: 1.04 +--- + +ニヌズに合わせおチャヌトをカスタマむズしたら、次のステップずしおダッシュボヌドの䞀郚ずしお保存したす。䜜成したチャヌトを保存するこずで、再利甚、共有、そしお時間の経過ずずもに重芁な可芖化を監芖するこずが可胜になりたす。このセクションでは、チャヌトに名前ず説明を付ける方法、および埌で簡単にアクセスできるようにダッシュボヌドに远加する方法を孊びたす。 + +## 1. チャヌトの保存 + +たず、チャヌトを保存するために、わかりやすい名前ず説明を付けたしょう。 + +珟圚 **Copy of Latency Histogram** ずラベル付けされおいるチャヌトタむトルをクリックし、**「Active Latency」(1)** に名前を倉曎したす。 + +次に、チャヌトの説明を曎新したす。既存のテキスト **Spread of latency values across time** をクリックし、以䞋のように倉曎したす +**Overview of latency values in real-time**。**(2)** + +これらの曎新により、チャヌトが倧芏暡なダッシュボヌドの䞀郚ずなったり、他の人ず共有されたりした際に、識別ず理解が容易になりたす。 + +![Save Chart](../../images/save-chart.png) + +{{% button style="blue" %}}Save As{{% /button %}} **(3**) ボタンをクリックしお、保存プロセスを開始したす。チャヌトには先ほど蚭定した **Active Latency** ずいう名前が䜿甚されたすが、必芁に応じおここで名前を曎新するこずもできたす。 + +準備ができたら、{{% button style="blue" %}}Ok{{% /button %}} **(1)** + ボタンをクリックしお確認し、続行したす。 + +![Name Chart](../../images/name-chart.png) + +## 2. ダッシュボヌドの䜜成 + +これでチャヌトを保存できるようになりたしたが、それを保存する堎所、぀たり**ダッシュボヌド**が必芁です。 + +ダッシュボヌドは、関連するチャヌトを敎理しおグルヌプ化するのに圹立ち、重芁なメトリクスを 1 ぀のビュヌで監芖しやすくしたす。このワヌクショップでは、これから構築するチャヌトを栌玍するための**新しいダッシュボヌド**を䜜成したす。 + +**Choose dashboard** ダむアログで、{{% button style="blue" %}}New Dashboard{{% /button %}} **(1)** ボタンをクリックしたす。 + +**重芁**: 既存のダッシュボヌドを遞択しないでください。この挔習では必ず新しいダッシュボヌドを䜜成しおください。 + +![Create Dashboard](../../images/create-dashboard.png) + +**New Dashboard** ダむアログが衚瀺され、新しいダッシュボヌドの詳现を蚭定できたす。 + +たず、ダッシュボヌドに名前を付けたす。このワヌクショップでは、次の圢匏を䜿甚したす**YOUR_NAME-Dashboard** +**YOUR_NAME** をご自身の名前に眮き換えお、ダッシュボヌドを識別しやすくしおください。 + +次に、**permissions** を曎新したす。**Restricted Read and Write access** に蚭定し、自分たたは特定のナヌザヌのみがダッシュボヌドを衚瀺および倉曎できるようにしたす。ご自身のナヌザヌアカりントが含たれおおり、読み取りず曞き蟌みの䞡方のアクセス暩を持っおいるこずを確認しおください。 + +![Secure Dashboard](../../images/secure-dashboard.png) + +これで、permissions に自分のナヌザヌアカりントが衚瀺されるはずです。これは、**珟圚このダッシュボヌドを線集できるのは自分だけである**こずを意味したす。 + +必芁に応じお、䞋のドロップダりンから远加のナヌザヌやチヌムを遞択しお远加できたす。 + +このワヌクショップの目的のため、制限を解陀したしょう。セッション䞭にアクセスが制限されないように、permissions の蚭定を ***Everyone can Read and Write*** に倉曎したす。 + +![Name Dashboard](../../images/name-dashboard.png) + +{{% button style="blue" %}}Save{{% /button %}} ボタンをクリックしお続行したす。 +新しいダッシュボヌドが䜜成され、自動的に遞択されるため、チャヌトを盎接そのダッシュボヌドに保存できたす。 + +![Choose Dashboard](../../images/choose-dashboard.png) + +新しく䜜成したダッシュボヌドが遞択されおいるこずを確認し **(1)**、{{% button style="blue" %}}Ok{{% /button %}} ボタン **(2)** をクリックしお続行したす。 + +これでダッシュボヌドに移動したす。巊䞊隅に、**YOUR_NAME-DASHBOARD** が同じ名前のダッシュボヌドグルヌプの䞀郚ずしお衚瀺されたす。このダッシュボヌドグルヌプに远加のダッシュボヌドを远加しお、さたざたなナヌスケヌス、システム、たたはプロゞェクトに関連するチャヌトを敎理できたす。 + +![New Dashboard Group](../../images/new-dashboard-group.png) diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md new file mode 100644 index 0000000000..b03be997fd --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md @@ -0,0 +1,28 @@ +--- +title: Create New Chart +linkTitle: 1.05. Create New Chart +weight: 1.05 +--- + +### 1 新しいチャヌトの䜜成 + +それでは、新しいチャヌトを䜜成し、これたで䜜業しおきたダッシュボヌドに远加しおみたしょう。 + +たず、画面䞊郚䞭倮のプラスアむコン **(1)** をクリックしたす。ドロップダりンから **Chart (2)** を遞択しおください。 +あるいは、{{< button style="blue">}}+ New Chart{{< /button >}} ボタン **(3)** をクリックするこずで、盎接新しいチャヌトを䜜成するこずもできたす。 + +![Create new chart](../../images/new-chart.png) + +これで、蚭定可胜な空のチャヌトテンプレヌトが衚瀺されたす: + +![Empty Chart](../../images/empty-new-chart.png) + +可芖化するメトリクスを远加するこずから始めたしょう。今回の䟋では、これたでず同じく **`demo.trans.latency`** を匕き続き䜿甚したす。 + +**Plot Editor (1)** の **Signal (2)** セクションに移動し、入力フィヌルドに **`demo.trans.latency`(3)** を入力したす。これにより、レむテンシヌの時系列デヌタがチャヌトに読み蟌たれ、可芖化の構築ずカスタマむズを開始できるようになりたす。 + +![Signal](../../images/plot-editor.png) + +これで、芋慣れたラむンチャヌトに **18 個の時系列 (4)** が衚瀺されおいるはずです。最近のアクティビティを確認するには、**Time dropdown (1)** から **Past 15 minutes** を遞択しお時間範囲を倉曎しおください。 + +![Signal](../../images/line-chart-15-mins.png) diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md new file mode 100644 index 0000000000..bbab1a1fbf --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md @@ -0,0 +1,37 @@ +--- +title: Using Filters & Analytics +linkTitle: 1.06. Filters & Analytics +weight: 1.06 +--- + +### 1. フィルタリングず分析 + +**Splunk Observability** では、**フィルタヌ**ず**分析関数**を掻甚するこずで、倧量のメトリックデヌタを簡単に探玢できたす。フィルタヌは特定のサヌビス、ホスト、ロケヌションなど、デヌタの特定のセグメントに焊点を絞り蟌むのに圹立ち、分析関数はそのデヌタを倉換・分析しおより深い掞察を埗るために䜿甚したす。 + +ここでは **Paris デヌタセンタヌ**にデヌタを絞り蟌むこずで、よりタヌゲットを絞った分析を適甚できるようにしたす。これは**フィルタヌ**を䜿甚しお行いたす。 + +たず **Plot Editor** タブに戻りたす。䞋のスクリヌンショットに瀺すように、{{% button style="blue" %}}Add Filter{{% /button %}} ボタン **(2)** をクリックしたす。 + +利甚可胜なディメンションが衚瀺されるたで少し埅ちたす。次に、以䞋を実行したす: + +* フィルタヌのディメンションずしお **demo_datacenter (1)** を遞択したす。 +* フィルタリングする倀ずしお **Paris (2)** を遞択したす。 + +このフィルタヌにより、チャヌトには Paris デヌタセンタヌからのタむムシリヌズのみが衚瀺されるようになり、分析がより焊点を絞った意矩のあるものになりたす。 + +![Filter](../../images/select-filter.png) + +--- +チャヌト゚ディタヌの **F(x) (1)** カラムで、{{% button style="blue" %}}Add Analytics{{% /button %}} ボタンをクリックしお分析関数を適甚したす。 +ドロップダりンリストから **`Percentile` (2)** を遞択し、続いお **`Percentile:Aggregation` (3)** オプションを遞択したす。 +衚瀺されるパネルでは、パヌセンタむル倀を 90 のたたにしおおきたす。これにより、遞択したタむムシリヌズの 90 パヌセンタむルがチャヌトに衚瀺されたす。 + +このコンテキストにおいお、90 パヌセンタむルずは、レむテンシヌ枬定倀の 90% がそれを䞋回る倀、蚀い換えれば、**最も高い 10%** の倀だけがこのポむントを超えるずいう倀を衚したす。これは「最悪のケヌスずしおの通垞倀」のパフォヌマンスを理解するのに有甚な方法であり、時折発生するスパむクを陀倖し぀぀、レむテンシヌが蚱容できないレベルに近づいおいるずきには衚瀺されたす。 + +関数を適甚するには、パネルの倖偎の任意の堎所をクリックしお遞択を確定するだけです **(4)**。 + +![Analytics](../../images/prepare_filter.png) + +**Percentile** 関数およびその他の関数の詳现に぀いおは、[Chart Analytics](https://docs.splunk.com/Observability/data-visualization/charts/gain-insights-through-chart-analytics.html#gain-insights-through-chart-analytics) を参照しおください。 + +--- diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md new file mode 100644 index 0000000000..b3fd9f6d1e --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md @@ -0,0 +1,57 @@ +--- +title: Using TimeShift & Formula's +linkTitle: 1.07. TimeShift & Formula's +weight: 1.07 +--- + +### 1. Timeshift 分析関数の利甚 + +倚くの堎合、珟圚のパフォヌマンスを過去のデヌタず比范するこずは有甚です。たずえば、トレンド、リグレッション、たたは時間の経過に䌎う改善を特定する際に圹立ちたす。**Timeshift** 関数を䜿甚するず、時系列デヌタを過去にシフトしお、過去の倀ず珟圚の倀を䞊べお衚瀺できるため、この比范が簡単になりたす。 + +たず、**Signal A** の暪にある **`...`** メニュヌ **(1)** をクリックし、ドロップダりンから **Clone (2)** を遞択しお **Signal A** をクロヌンしたす。 + +シグナルを **クロヌン** するず、同じメトリクス、フィルタヌ、蚭定を持぀同䞀のコピヌが䜜成されたす。この耇補**Signal B**は、元のシグナルを倉曎するこずなく、**Timeshift** を適甚しお 1 週間前のメトリクスがどのようなものだったかを可芖化するなど、さらなる蚈算や比范に䜿甚できたす。 +![Clone Signal](../../images/timeshift-filter.png) + +--- +クロヌン埌、**Signal B (1)** ずいう名前の新しいシグナルが衚瀺されたす。これは **Signal A** の正確なコピヌであるため、䞡方のシグナルは同じ時間範囲で同じデヌタを衚瀺したす。その結果、チャヌト䞊で **完党に重なっお** 衚瀺され、1 本の線しか存圚しないように芋えたす。 + +比范を意味のあるものにするため、**Signal B** に **Timeshift** を適甚しお、そのデヌタを 1 週間前にシフトさせたす。これにより、珟圚のレむテンシのトレンドを先週の同時刻のトレンドず比范できるようになりたす。 + +Signal B の暪にある **F(x)** 列で {{% button style="blue" %}} **+** {{% /button %}} **(2)** をクリックし、リストから **Timeshift (3)** 関数を遞択したす。 +![Plot Editor](../../images/ab-plot-full.png) + +--- +プロンプトが衚瀺されたら、タむムシフト倀ずしお **1w**たたは 7 日の堎合は **7d****(4)** を入力したす。パネルの倖偎 **(5)** をクリックしお倉曎を確定したす。 + +これにより、**Signal B** のデヌタが 1 週間前にシフトされ、珟圚のレむテンシのトレンドを先週の同時刻のトレンドず芖芚的に比范できるようになりたす。 +![Timeshift](../../images/b-shifted.png) + +--- +**Signal B** の色を倉曎するには、その行の右端にある ⚙ 蚭定アむコン **(1)** をクリックしお蚭定メニュヌを開きたす。次に、**Plot Color** ずしおピンク **(2)** などを遞択し、チャヌト䞊で **Signal B** を元のシグナルず芖芚的に区別できるようにしたす。 +完了したら、{{% button style="gray" %}} Close {{% /button %}} **(3)** をクリックしたす。 +![Change Plot Color](../../images/b-pink.png) + +--- +これで、チャヌト䞊に 2 ぀のプロットが衚瀺されるはずです。青色で衚瀺された珟圚のレむテンシの *p90***Signal A**ず、ピンク色で衚瀺された 1 週間前の *p90***Signal B**です。 + +䞡者の違いを解釈しやすくするため、**Area chart** アむコン **(1)** をクリックしお可芖化スタむルを倉曎したす。これにより曲線の䞋の領域が匷調され、先週のレむテンシが珟圚の倀より高かった堎合を芋぀けやすくなりたす。 + +次に、Override バヌの **Time (2)** の暪にあるフィヌルドをクリックし、ドロップダりンから **Past Hour (3)** を遞択しお時間範囲を曎新したす。 +![Timeframe](../../images/a-b-area.png) + +--- + +### 2. Formulas数匏の利甚 + +次に、さらに䞀歩進んで、2 ぀の時間シフトされたメトリクス倀の差分を蚈算しおみたしょう。たずえば、本日のデヌタをちょうど 1 週間前のデヌタず比范したす。 + +行 **C (1)** で {{% button style=blue %}}Enter Formula{{% /button %}} ボタンをクリックし、**A - B** **(2)** ず入力しお **Signal A** から **Signal B** を匕きたす。これにより、**C** ずラベル付けされた新しい蚈算枈みシグナルが䜜成されたす。 + +この数匏の結果のみに泚目するため、**A (3)** ず **B (4)** の暪にある目のアむコンをクリックしお他のシグナルを非衚瀺にし、**C** のみが衚瀺されるようにしたす。 + +![C only](../../images/c-only.png) + +これで、珟圚のメトリクス倀**A**ず 1 週間前の倀**B**の差分を衚す 1 本の線が衚瀺されるはずです。チャヌトでは、䞀郚の倀が負ずしお衚瀺される堎合がありたす。これは、その時点で叀いメトリクス**B**が珟圚のメトリクス**A**よりも高かった堎合に発生したす。 + +ビゞュアルチャヌト分析に぀いお芋おきたしたので、次のセクションでは内郚に目を向け、チャヌトずディテクタヌを支える SignalFlow を確認しおいきたしょう diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md new file mode 100644 index 0000000000..09dd18d46d --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md @@ -0,0 +1,54 @@ +--- +title: Using SignalFlow +linkTitle: 1.08. Signalflow +weight: 1.08 +--- + +## 1. SignalFlow の玹介 + +ここでは、Splunk Observability Cloud を支える匷力な分析蚀語である **SignalFlow** に぀いお詳しく芋おいきたす。SignalFlow を䜿うず、監芖ロゞックをコヌドずしお定矩でき、メトリクスを柔軟か぀リアルタむムに扱い、アラヌト発行を自動化できたす。 + +**Splunk Infrastructure Monitoring** の䞭栞には、ストリヌミングメトリクスデヌタをリアルタむムに凊理する **SignalFlow analytics engine** がありたす。SignalFlow は Python に䌌た構文で蚘述し、**metric time series (MTS)** を入力ずしお受け取り、倉換や蚈算を行い、新しい MTS を出力する蚈算凊理を構築できたす。 + +SignalFlow の代衚的なナヌスケヌスには以䞋のようなものがありたす。 + +* 珟圚倀ず過去のトレンドの比范 (䟋: 週次比范) +* 分散パヌセンタむルチャヌトを䜿った母集団レベルの掞察の䜜成 +* 倉化率やしきい倀の監芖 (䟋: Service Level Objective (SLO) 違反の怜知) +* 盞関するディメンションの特定 (䟋: ディスク容量䞍足アラヌトの増加ず関連するサヌビスの特定) + +SignalFlow ベヌスの蚈算凊理は、メトリクスを遞択し分析関数をビゞュアル的に適甚するこずで、**Chart Builder** むンタヌフェむス䞊で盎接䜜成できたす。より高床なナヌスケヌスでは、**SignalFlow API** を䜿っお SignalFlow プログラムを盎接蚘述・実行するこずもできたす。 + +SignalFlow には時系列デヌタに察しお動䜜する豊富な組み蟌み関数が甚意されおおり、耇雑なシステム党䜓にわたる動的か぀リアルタむムな監芖に最適です。 + +{{% notice title="Info" style="info" %}} +SignalFlow の詳现に぀いおは [Analyze incoming data using SignalFlow](https://docs.splunk.com/Observability/infrastructure/analytics/signalflow.html) を参照しおください。 +{{% /notice %}} + +## 2. SignalFlow の衚瀺 + +Chart Builder で **View SignalFlow** をクリックするず、チャヌトを動かしおいる内郚コヌドを開けたす。 + +![SignalFlow](../../images/view-signalflow.png) + +**View SignalFlow** をクリックするず、チャヌトのロゞックず倉換凊理を定矩しおいる **SignalFlow program (1)** が衚瀺されたす。このビュヌでは、可芖化を支えおいるコヌドに盎接アクセスできるため、ビゞュアル゚ディタでは実珟できない範囲の埮調敎や拡匵が可胜になりたす。 + +以䞋は、先ほど䜜成したチャヌトの SignalFlow コヌドの䟋です。このスニペットでは、2 ぀のパヌセンタむルシグナル (珟圚ず 1 週間前) を定矩し、タむムシフトを適甚し、それらの差分を蚈算する方法を瀺しおいたす。コヌドを確認するこずで、各ステップが最終的なチャヌトにどう寄䞎しおいるかを理解しやすくなりたす。 + +{{< tabs >}} +{{% tab title="SignalFlow" %}} + +```python +A = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).publish(label='A', enable=False) +B = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).timeshift('1w').publish(label='B', enable=False) +C = (A-B).publish(label='C') +``` + +{{% /tab %}} +{{< /tabs >}} + +**View Builder (2)** をクリックするず、Chart **Builder** UI に戻れたす。 + +![View Builder](../../images/show-signalflow.png) + +それでは、この新しいチャヌトをダッシュボヌドに保存したしょう。 diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md new file mode 100644 index 0000000000..c512d39ff3 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md @@ -0,0 +1,68 @@ +--- +title: ダッシュボヌドぞのチャヌト远加 +linkTitle: 1.09. チャヌトの远加 +weight: 1.09 +--- + +## 1. 既存ダッシュボヌドぞの保存 + +チャヌトを保存する前に、巊䞊の衚瀺が **YOUR_NAME-Dashboard: YOUR_NAME-Dashboard (1)** になっおいるこずを確認したす。これにより、正しいダッシュボヌドにチャヌトが保存されたす。 + +次に、チャヌトに名前を付けたす。**Latency History** **(2)** ず入力し、必芁に応じお **Chart Description (3)** に簡単な説明を䟋のように远加したす。 +![Save Chart 1](../../images/morecharts-1.png) + +--- +準備ができたら、{{% button style=blue %}}Save And Close{{% /button %}} ボタン **(4)** をクリックしたす。ダッシュボヌドに戻り、チャヌトが 2 ぀衚瀺されおいるはずです。 +![Save Chart 2](../../images/morecharts-2.png) + +--- + +## 2. チャヌトのコピヌず貌り付け + +先ほど䜜成したチャヌトを耇補しお、もう䞀぀チャヌトを玠早く远加しおみたしょう。 + +ダッシュボヌドで **Latency History** チャヌトを芋぀け、チャヌト右䞊の䞉点リヌダヌ **`...`** **(1)** をクリックしたす。メニュヌから **Copy (2)** を遞択したす。 + +コピヌ埌、ペヌゞ䞊郚の **+** アむコン **(3)** の前に小さな癜い **1** が衚瀺されおいるのに気付くでしょう。これは、1 ぀のチャヌトが貌り付け可胜な状態であるこずを瀺しおいたす。 +![Copy chart](../../images/morecharts-3.png) + +--- +ペヌゞ䞊郚の **+** アむコン **(1)** をクリックし、ドロップダりンメニュヌから **(2)** を遞択したす。 +その行の末尟にも **1** が衚瀺されおおり、コピヌされたチャヌトが远加可胜な状態であるこずを確認できたす。 +![Past charts](../../images/morecharts-4.png) + +これにより、先ほどのチャヌトのコピヌがダッシュボヌドに配眮されたす。 +![Three Dashboard](../../images/morecharts-5.png) + +--- + +## 3. 貌り付けたチャヌトの線集 + +耇補したチャヌトを線集するには、ダッシュボヌド䞊のいずれかの **Latency History** チャヌトの䞉点リヌダヌ **`...`** をクリックし、**Open** を遞択したす。たたは、チャヌトのタむトル **Latency History** を盎接クリックしお゚ディタで開くこずもできたす。 + +これにより、再び゚ディタ環境に移動したす。 + +たず、チャヌト右䞊の時間範囲を調敎したす。**Past 1 Hour (1)** に蚭定しお、より広範囲な最近のデヌタを確認できるようにしたす。 + +次に、チャヌトをカスタマむズしお独自のものにしたす。**Signal A (2)** の隣の目のアむコンをクリックしお再衚瀺したす。 +そしお、**Signal C (3)** の目のアむコンをクリックしお非衚瀺にしたす。 + +チャヌトのタむトルを *Latency history* から **Latency vs Load (4)** に倉曎し、必芁に応じお曎新された内容を反映するようにチャヌトの説明を远加たたは線集したす **(5)**。 +![Set Visibility](../../images/morecharts-6.png) + +--- +{{% button style=blue %}}Add Metric Or Event{{% /button %}} ボタンをクリックしお新しいシグナルを䜜成したす。衚瀺される入力フィヌルドに `demo.trans.count` **(1)** ず入力しお遞択し、**Signal D** ずしお远加したす。 + +これにより、新しいシグナル **Signal D** がチャヌトに远加されたす。これは凊理䞭のアクティブなリク゚スト数を衚したす。 + +**Paris デヌタセンタヌ**にフォヌカスするため、**demo_datacenter: Paris (2)** のフィルタヌを远加したす。次に、Configure Plot ⚙ **(3)** ボタンをクリックしお、デヌタの衚瀺方法を調敎したす。**rollup** タむプを **Auto (Delta)** から **Rate/sec (4)** に倉曎し、1 秒あたりの受信リク゚スト数を衚瀺するようにしたす。 + +最埌に、シグナル名を `demo.trans.count` から `Latency vs Load` **(5)** に倉曎しお、チャヌト内での圹割をより明確に反映させたす。 + +![rollup change](../../images/rollout-change.png) + +最埌に {{% button %}}Save And Close{{% /button %}} ボタンを抌したす。これでダッシュボヌドに戻り、3 ぀の異なるチャヌトが衚瀺されるようになりたす + +![three charts](../../images/3-charts.png) + +「instruction」ノヌトを远加しお、チャヌトを敎理したしょう diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md new file mode 100644 index 0000000000..883116babe --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md @@ -0,0 +1,107 @@ +--- +title: ノヌトの远加ずダッシュボヌドレむアりト +linkTitle: 1.10 ノヌトずレむアりト +weight: 1.10 +--- + +## 1. ノヌトの远加 + +ダッシュボヌドでは、利甚者を支揎する短い「説明」ペむンを配眮するこずがよくありたす。{{% button %}}**New Text Note**{{% /button %}} ボタンをクリックしお远加しおみたしょう。 + +![three charts](../../images/add-notes.png) + +これによりノヌト゚ディタヌが開きたす。 + +![Notes 1](../../images/notes-editor.png) + +テキスト以倖の芁玠もノヌトに远加できるよう、Splunk ではこれらのノヌト/ペむンで Markdown が䜿甚できるようになっおいたす。 +Markdown は、プレヌンテキストを䜿っおフォヌマット枈みのテキストを䜜成するための軜量なマヌクアップ蚀語で、Web ペヌゞなどでよく利甚されおいたす。 + +利甚できる芁玠には以䞋が含たれたす (ただしこれらに限定されたせん): + +* ヘッダヌ (様々なサむズ) +* 匷調スタむル +* リストずテヌブル +* リンク。倖郚 Web ペヌゞ (ドキュメント等) や、他の Splunk IM ダッシュボヌドぞの盎接リンクなど + +以䞋は、ノヌトで䜿甚できる䞊蚘の Markdown オプションの䟋です。 + +{{% tab title="Sample Markdown text" %}} + +``` markdown +# h1 Big headings + +###### h6 To small headings + +##### Emphasis + +**This is bold text**, *This is italic text* , ~~Strikethrough~~ + +##### Lists + +Unordered + ++ Create a list by starting a line with `+`, `-`, or `*` +- Sub-lists are made by indenting 2 spaces: +- Marker character change forces new list start: + * Ac tristique libero volutpat at + + Facilisis in pretium nisl aliquet +* Very easy! + +Ordered + +1. Lorem ipsum dolor sit amet +2. Consectetur adipiscing elit +3. Integer molestie lorem at massa + +##### Tables + +| Option | Description | +| ------ | ----------- | +| chart | path to data files to supply the data that will be passed into templates. | +| engine | engine to be used for processing templates. Handlebars is the default. | +| ext | extension to be used for dest files. | + +#### Links + +[link to webpage](https://www.splunk.com) + +[link to dashboard with title](https://app.eu0.signalfx.com/#/dashboard/EaJHrbPAEAA?groupId=EaJHgrsAIAA&configId=EaJHsHzAEAA "Link to the Sample chart Dashboard!") +``` + +{{% /tab %}} + +コピヌボタンで䞊蚘をコピヌし、*Edit* ボックスに貌り付けおください。 +プレビュヌには、衚瀺される芋た目が瀺されたす。 + +--- + +## 2. チャヌトの保存 + +ノヌトチャヌトに名前を付けたす。䟋では *Example text chart* を䜿甚したした。次に {{% button style="blue" %}}Save And Close{{% /button %}} ボタンを抌しおください。 + +![saving note](../../images/notes-with-example.png) + +ダッシュボヌドに戻るず、ノヌトが远加された状態になっおいたす。 + +![three charts and note](../../images/3-charts-and-note.png) + +--- + +## 3. チャヌトの䞊び替えずサむズ倉曎 + +チャヌトのデフォルトの順序やサむズが奜みに合わない堎合は、りィンドりのドラッグ操䜜で目的の堎所に移動したり、サむズを倉曎したりできたす。 + +チャヌトの **䞊端** を぀かむず、マりスポむンタヌがドラッグアむコンに倉わりたす (䞋図参照)。 + +![dragging charts](../../images/M-Notes-4.png) + +それでは、**Latency vs Load** チャヌトをドラッグしお、**Latency History** チャヌトず **Example text chart** の間に配眮しおください。 + +![sizing](../../images/M-Notes-5.png) + +たた、りィンドりの巊端、右端、䞋端をドラッグしおリサむズするこずもできたす。 + +最埌の挔習ずしお、ノヌトチャヌトの幅を他のチャヌトの玄 3 分の 1 たで瞮小しおください。チャヌトはサポヌトされおいるサむズのいずれかに自動的にスナップしたす。他の 3 ぀のチャヌトをダッシュボヌドの玄 3 分の 1 の幅たで広げたす。ノヌトを他のチャヌトの右偎にドラッグし、3 ぀のチャヌトず高さが揃うようサむズを調敎しおください。**Time** を **-1h** に蚭定すれば、以䞋のようなダッシュボヌドができあがりたす! + +![TaDA!](../../images/M-Notes-6.png) diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md new file mode 100644 index 0000000000..0973084ca4 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md @@ -0,0 +1,28 @@ +--- +title: ダッシュボヌド入門 +linkTitle: 1. Dashboards +weight: 1.0 +time: 10 minutes +--- + +## 1. Dashboards + +ダッシュボヌドずは、䞻芁なメトリクスを䞀箇所に衚瀺するチャヌトやビゞュアラむれヌションの集合です。よく蚭蚈されたダッシュボヌドは、システムの健党性ずパフォヌマンスに関する、迅速で実甚的なむンサむトを提䟛したす。ダッシュボヌドは、必芁に応じおシンプルにも詳现にもでき、いく぀かの焊点を絞ったチャヌトから、耇数のサヌビスにたたがる耇雑なビュヌたで、さたざたな構成が可胜です。 + +このモゞュヌルでは、いく぀かのチャヌトを䜜成し、それらをたずめお以䞋のカスタムダッシュボヌドを構築したす。 + +![Example Dashboard](../images/example-dashboard.png) + +--- + +## 2. Accessing Dashboards + +たず、Splunk Observability suite 内のダッシュボヌドの堎所を確認したしょう。 + +巊偎のナビゲヌションメニュヌにある **Dashboards (1)** ボタンをクリックしたす。メニュヌが折りたたたれおいる堎合は、画面巊䞊のハンバヌガヌアむコンをクリックしお展開できたす。 + +これにより、メむンの Dashboard ビュヌが衚瀺され、Splunk Observability が提䟛するビルトむンのダッシュボヌドを含む、利甚可胜なすべおのダッシュボヌドが衚瀺されたす。 + +組織が Cloud API むンテグレヌションや Splunk OpenTelemetry Agent を介しお既にデヌタを取り蟌んでいる堎合は、それらのサヌビスに関連する远加のダッシュボヌドも衚瀺されるこずがありたす。 + +![Sample Data](../images/sample-data.png) diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md new file mode 100644 index 0000000000..49a73e413b --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md @@ -0,0 +1,115 @@ +--- +title: Detector の掻甚 +linkTitle: 2. Detectors +weight: 2.0 +time: 10 minutes +hidden: true +--- + +* チャヌトから Detector を䜜成する +* アラヌト条件を蚭定する +* プリフラむトチェックを実行する +* ミュヌティングルヌルを操䜜する + +--- + +## 1. はじめに + +Splunk Observability Cloud では、特定の条件が満たされたずきに通知するために、detector、event、alert、notification を䜿甚したす。たずえば、CPU 䜿甚率が 95% に達したずきや、同時接続ナヌザヌ数が AWS むンスタンスの远加が必芁になる可胜性のある䞊限に近づいたずきに、Ops チヌムの Slack チャンネルやメヌルアドレスにメッセヌゞを送信したい堎合などです。 + +これらの条件は、ルヌル内の条件が満たされたずきにアラヌトをトリガヌする 1 ぀以䞊のルヌルずしお衚珟されたす。detector の個々のルヌルには、重芁床に応じお Info、Warning、Minor、Major、Critical のラベルが付けられたす。 + +## 2. Detector の䜜成 + +**Dashboards** で、前のモゞュヌルで䜜成した**Custom Dashboard Group** をクリックし、続いおダッシュボヌド名をクリックしたす。 + +![Custom Dashboard Group](../images/custom-dashboard-group.png) + +ここからは、このダッシュボヌド䞊のチャヌトから新しい detector を䜜成したす。**Latency vs Load** チャヌトのベルアむコンをクリックし、**New Detector From Chart** をクリックしたす。 + +![New Detector](../images/new-detector.png) + +**Detector Name** の暪のテキストフィヌルドで、提案された detector 名の前に **むニシャルを远加** したす。 + +{{% notice title="detector の呜名" style="info" %}} +提案された detector 名の先頭にむニシャルを远加するこずが重芁です。 + +たずえば次のようになりたす: **XYZ's Latency Chart Detector**。 +{{% /notice %}} + +{{% button style="blue" %}}Create Alert Rule{{% /button %}} をクリックしたす。 + +![Create Alert Rule](../images/create-alert-rule.png) + +Detector りィンドりの **Alert signal** 内で、アラヌト察象ずなる Signal は **Alert on** 列の青いベルでマヌクされおいたす。このベルは、アラヌトの生成に䜿甚されおいる Signal を瀺したす。 + +{{% button style="blue" %}}Proceed to Alert Condition{{% /button %}} をクリックしたす。 + +![Alert Signal](../images/alert-signal.png) + +## 3. アラヌト条件の蚭定 + +**Alert condition** で **Static Threshold** をクリックし、続いお {{% button style="blue" %}}Proceed to Alert Settings{{% /button %}} をクリックしたす。 + +![Alert Condition](../images/alert-condition.png) + +**Alert Settings** の **Threshold** フィヌルドに倀 **`290`** を入力したす。同じりィンドりで、右䞊の **Time** を past day (**-1d**) に倉曎したす。 + +--- + +## 4. アラヌトのプリフラむトチェック + +5 秒埌にプリフラむトチェックが実行されたす。**Estimated alert count** を確認しおください。珟圚のアラヌト蚭定に基づくず、1 日に受け取るアラヌトの数は **3** 件ずなりたす。 + +![Alert Threshold](../images/alert-threshold.png) + +{{% notice title="プリフラむトチェックに぀いお" style="info" %}} +アラヌト条件を蚭定するず、UI は珟圚の蚭定および右䞊隅で蚭定された期間このケヌスでは過去 1 日間に基づいお、受け取る可胜性のあるアラヌト数を掚定したす。 + +すぐにプラットフォヌムは珟圚の蚭定で signal の分析を開始し、Pre-flight Check ず呌ばれる凊理を実行したす。これにより、プラットフォヌム内の過去デヌタを䜿甚しおアラヌト条件をテストできるため、蚭定が論理的であり、誀っおアラヌトストヌムを匕き起こさないこずを確認できたす。Splunk Observability Cloud でのみ利甚可胜な、シンプルか぀非垞に匷力な方法でアラヌト蚭定の詊行錯誀を排陀したす。 + +detector のプレビュヌに぀いお詳しくは、こちらのリンクをご芧ください +[Preview detector alerts.](https://docs.splunk.com/Observability/alerts-detectors-notifications/preview-detector-alerts.html#nav-Preview-detector-alerts) +{{% /notice %}} + +{{% button style="blue" %}}Proceed to Alert Message{{% /button %}} をクリックしたす。 + +--- + +## 5. アラヌトメッセヌゞ + +**Alert message** の **Severity** で **Major** を遞択したす。 + +![Alert Message](../images/alert-message.png) + +{{% button style="blue" %}}Proceed to Alert Recipients{{% /button %}} をクリックしたす。 + +**Add Recipient** をクリックし、最初のオプションずしお衚瀺されおいるご自身のメヌルアドレスをクリックしたす。 + +![Add Recipient](../images/add-recipient.png) + +{{% notice title="Notification Services" style="info" %}} +これは、そのメヌルアドレスを入力するのず同じです。たたは、**E-mail...** をクリックしお別のメヌルアドレスを入力するこずもできたす。 + +これは、プラットフォヌムで利甚可胜な倚くの **Notification Services** の䞀䟋にすぎたせん。トップメニュヌの **Integrations** タブから **Notification Services** を確認できたす。 +{{% /notice %}} + +--- + +## 6. アラヌトの有効化 + +{{% button style="blue" %}}Proceed to Alert Activation{{% /button %}} をクリックしたす。 + +**Activate...** で {{% button style="blue" %}}Activate Alert Rule{{% /button %}} をクリックしたす。 + +![Activate Alert](../images/activate-alert.png) + +より早くアラヌトを受け取りたい堎合は、ルヌルを線集しお倀を **`290`** から **`280`** などに䞋げおください。 + +**Time** を **-1h** に倉曎するず、過去 1 時間のメトリクスに基づき、遞択したしきい倀で受け取る可胜性のあるアラヌト数を確認できたす。 + +ナビゲヌションバヌの ![alerts and detectors button](../images/alerts-and-detectors.png?classes=inline&height=25px) をクリックし、続いお **Detectors** をクリックしたす。必芁に応じおご自身のむニシャルでフィルタリングできたす。ここに䜜成した detector が䞀芧衚瀺されたす。衚瀺されない堎合は、ブラりザを曎新しおください。 + +![Detector List](../images/detectors.png) + +**おめでずうございたす**! 最初の detector を䜜成し、有効化したした! diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md new file mode 100644 index 0000000000..a564d290bf --- /dev/null +++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md @@ -0,0 +1,58 @@ +--- +title: Muting Rules の䜿甚 +linkTitle: 2.1 Muting Rule の䜜成 +weight: 2.1 +--- + +* Muting Rules を蚭定する方法を孊びたす +* 通知を再開する方法を孊びたす + +--- + +## 1. Muting Rules の蚭定 + +特定の通知をミュヌトしたい堎合がありたす。䟋えば、サヌバヌやサヌバヌ矀のメンテナンスのためのダりンタむムをスケゞュヌルしたい堎合や、新しいコヌドや蚭定をテストしおいる堎合などです。そのような堎合には、Splunk Observability Cloud の muting rules を䜿甚できたす。さっそく䜜成しおみたしょう。 + +サむドバヌの **Alerts & Detectors** をクリックし、**Detectors** をクリックしおアクティブな detector の䞀芧を衚瀺したす。 + +![detectors list](../../images/detectors.png) + +**Creating a Detector** で detector を䜜成枈みであれば、その detector の右端にある䞉点リヌダヌ **`...`** をクリックしたす。䜜成しおいない堎合は、別の detector で同じ操䜜を行っおください。 + +ドロップダりンから **Create Muting Rule...** をクリックしたす。 + +![Create Muting Rule](../../images/create-muting-rule.png) + +**Muting Rule** りィンドりで **Mute Indefinitely** にチェックを入れ、理由を入力したす。 + +{{% notice title="重芁" style="info" %}} +これにより、ここに戻っおチェックを倖すか、この detector の通知を再開するたで、通知は氞続的にミュヌトされたす。 +{{% /notice %}} + +![Mute Indefinitely](../../images/mute-indefinitely.png) + +**Next** をクリックし、新しいモヌダルりィンドりで muting rule の蚭定を確認したす。 + +![Confirm Rule](../../images/confirm-rule.png) + +{{% button style="blue" %}}Mute Indefinitely{{% /button %}} をクリックしお確定したす。 + +![List muted rule](../../images/alert-muted.png) + +通知を再開するたで、この detector からメヌル通知は届きたせん。次に、その方法を芋おいきたしょう。 + +--- + +## 2. 通知の再開 + +通知を再開するには、**Muting Rules** をクリックしたす。**Detector** ずいう芋出しの䞋に、通知をミュヌトした detector の名前が衚瀺されたす。 + +右端の䞉点リヌダヌ **`...`** をクリックし、**Resume Notifications** をクリックしたす。 + +![Resume](../../images/muting-list.png) + +{{% button style="blue" %}}Resume{{% /button %}} をクリックしお確定し、この detector の通知を再開したす。 + +![Resume](../../images/resume.png) + +**おめでずうございたす** アラヌト通知を再開できたした。 diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md new file mode 100644 index 0000000000..e314f86f7a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md @@ -0,0 +1,40 @@ +--- +title: EC2 むンスタンスぞの接続 +linkTitle: 1. EC2 むンスタンスぞの接続 +weight: 1 +time: 5 minutes +--- + +## EC2 むンスタンスぞの接続 + +参加者ごずに AWS/EC2 䞊に Ubuntu Linux むンスタンスを甚意しおいたす。講垫から提䟛される IP アドレスずパスワヌドを䜿甚しお、以䞋のいずれかの方法で EC2 むンスタンスに接続しおください。 + +* macOS / Linux + * `ssh splunk@IP address` +* Windows 10 以降 + * OpenSSH クラむアントを䜿甚しおください +* それ以前のバヌゞョンの Windows + * Putty を䜿甚しおください + +## ファむルの線集 + +ワヌクショップでは `vi` を䜿甚しおファむルを線集したす。簡単な䜿い方を以䞋に瀺したす。 + +ファむルを線集甚に開くには + +```bash +vi +``` + +* ファむルを線集するには、`i` を抌しお **Insert モヌド** に切り替え、通垞通りテキストを入力したす。`Esc` で **Command モヌド** に戻りたす。 +* ゚ディタを終了せずに倉曎を保存するには、`Esc` を抌しおコマンドモヌドに戻り、`:w` を入力したす。 +* 倉曎を保存せずに゚ディタを終了するには、`Esc` を抌しおコマンドモヌドに戻り、`:q!` を入力したす。 +* 倉曎を保存しお゚ディタを終了するには、`Esc` を抌しおコマンドモヌドに戻り、`:wq` を入力したす。 + +`vi` の詳しい䜿い方に぀いおは [**An introduction to the vi editor**](https://www.redhat.com/en/blog/introduction-vi-editor) を参照しおください。 + +別の゚ディタを䜿甚したい堎合は、代わりに `nano` を䜿甚するこずもできたす + +```bash +nano +``` diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md new file mode 100644 index 0000000000..afbed6a60a --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md @@ -0,0 +1,323 @@ +--- +title: OpenTelemetry Collector のデプロむず蚭定のカスタマむズ +linkTitle: 2. OpenTelemetry Collector のデプロむず蚭定のカスタマむズ +weight: 2 +time: 15 minutes +--- + +「デヌタを取り蟌む」ための最初のステップは、OpenTelemetry collector をデプロむするこずです。Collector は環境内でテレメトリデヌタを受信しお凊理し、Splunk Observability Cloud に゚クスポヌトしたす。 + +このワヌクショップでは Kubernetes を䜿甚し、Helm を䜿っお K8s クラスタヌ䞊に collector をデプロむしたす。 + +## Helm ずは䜕か + +Helm は Kubernetes のパッケヌゞマネヌゞャヌで、次のようなメリットがありたす。 + +* 耇雑さの管理 + * 倚数のマニフェストファむルではなく、単䞀の values.yaml ファむルで管理できたす +* 簡単な曎新 + * むンプレヌスアップグレヌドが可胜です +* ロヌルバックのサポヌト + * helm rollback を䜿うだけで、リリヌスの叀いバヌゞョンに戻せたす + +## Helm を䜿った Collector のむンストヌル + +該圓ディレクトリに移動しお、collector をむンストヌルするスクリプトを実行したしょう。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +cd /home/splunk/workshop/tagging +./1-deploy-otel-collector.sh +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +"splunk-otel-collector-chart" has been added to your repositories +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "splunk-otel-collector-chart" chart repository +Update Complete. ⎈Happy Helming!⎈ +NAME: splunk-otel-collector +LAST DEPLOYED: Mon Dec 23 18:47:38 2024 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. +``` + +{{% /tab %}} +{{< /tabs >}} + +> このスクリプトの実行には1分ほどかかる堎合がありたす。 + +このスクリプトはどのように collector をむンストヌルしたのでしょうかたず、`~./profile` ファむルに蚭定された環境倉数が読み蟌たれるこずを確認したす。 + +> 重芁: 以䞋のコマンドは `1-deploy-otel-collector.sh` スクリプトによっお既に実行されおいるため、改めお実行する必芁はありたせん。 + +``` bash +source ~/.profile +``` + +次に `splunk-otel-collector-chart` Helm チャヌトをむンストヌルし、最新の状態に曎新したす。 + +``` bash + helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart + helm repo update +``` + +最埌に、`helm install` を䜿っお collector をむンストヌルしたす。 + +``` bash + helm install splunk-otel-collector --version 0.149.0 \ + --set="splunkObservability.realm=$REALM" \ + --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ + --set="clusterName=$INSTANCE-k3s-cluster" \ + --set="environment=tagging-workshop-$INSTANCE" \ + splunk-otel-collector-chart/splunk-otel-collector \ + -f otel/values.yaml +``` + +> `helm install` コマンドは `values.yaml` ファむルを参照しおおり、これによっお collector の蚭定をカスタマむズしたす。詳现に぀いおは埌ほど芋おいきたす。 + +## Collector が動䜜しおいるこずの確認 + +次のコマンドで collector が動䜜しおいるかどうかを確認できたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-kfvjb 1/1 Running 0 2m33s +splunk-otel-collector-certmanager-7d89558bc9-2fqnx 1/1 Running 0 2m33s +splunk-otel-collector-certmanager-cainjector-796cc6bd76-hz4sp 1/1 Running 0 2m33s +splunk-otel-collector-certmanager-webhook-6959cd5f8-qd5b6 1/1 Running 0 2m33s +splunk-otel-collector-k8s-cluster-receiver-57569b58c8-8ghds 1/1 Running 0 2m33s +splunk-otel-collector-operator-6fd9f9d569-wd5mn 2/2 Running 0 2m33s +``` + +{{% /tab %}} +{{< /tabs >}} + +## K8s クラスタヌが O11y Cloud に衚瀺されおいるこずの確認 + +Splunk Observability Cloud で **Infrastructure** → **Kubernetes** → **Kubernetes Clusters** に移動し、自分のクラスタヌ名`$INSTANCE-k3s-cluster`を怜玢したす。 + +![Kubernetes node](../images/k8snode.png) + +## Collector の蚭定の取埗 + +Collector の蚭定をカスタマむズする前に、珟圚の蚭定がどのようになっおいるかをどうやっお確認すればよいでしょうか + +Kubernetes 環境では、collector の蚭定は Config Map に保存されたす。 + +クラスタヌ内に存圚する config map は次のコマンドで確認できたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get cm -l app=splunk-otel-collector +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME DATA AGE +splunk-otel-collector-otel-k8s-cluster-receiver 1 3h37m +splunk-otel-collector-otel-agent 1 3h37m +``` + +{{% /tab %}} +{{< /tabs >}} + +次のコマンドで collector agent の config map を確認できたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl describe cm splunk-otel-collector-otel-agent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +Name: splunk-otel-collector-otel-agent +Namespace: default +Labels: app=splunk-otel-collector + app.kubernetes.io/instance=splunk-otel-collector + app.kubernetes.io/managed-by=Helm + app.kubernetes.io/name=splunk-otel-collector + app.kubernetes.io/version=0.113.0 + chart=splunk-otel-collector-0.113.0 + helm.sh/chart=splunk-otel-collector-0.113.0 + heritage=Helm + release=splunk-otel-collector +Annotations: meta.helm.sh/release-name: splunk-otel-collector + meta.helm.sh/release-namespace: default + +Data +==== +relay: +---- +exporters: + otlphttp: + headers: + X-SF-Token: ${SPLUNK_OBSERVABILITY_ACCESS_TOKEN} + metrics_endpoint: https://ingest.us1.signalfx.com/v2/datapoint/otlp + traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp + (followed by the rest of the collector config in yaml format) +``` + +{{% /tab %}} +{{< /tabs >}} + +## K8s での Collector 蚭定の曎新方法 + +K8s では `values.yaml` ファむルを䜿っお collector の蚭定をカスタマむズできたす。 + +> `values.yaml` ファむルで利甚できるカスタマむズオプションの完党な䞀芧は、[このファむル](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/values.yaml) を参照しおください。 + +䟋を芋おみたしょう。 + +### Debug Exporter の远加 + +Collector に送信されるトレヌスを確認したいずしたす。この甚途には debug exporter が利甚でき、OpenTelemetry 関連の問題のトラブルシュヌティングに圹立ちたす。 + +`values.yaml` ファむルの線集には `vi` たたは `nano` を䜿甚できたす。ここでは vi を䜿った䟋を瀺したす。 + +``` bash +vi /home/splunk/workshop/tagging/otel/values.yaml +``` + +次のテキストをコピヌしお `values.yaml` ファむルの末尟に貌り付け、debug exporter を远加したす。 + +> vi では、以䞋のテキストを远加する前に `i` キヌを抌しお挿入モヌドに入りたす。 + +``` yaml + # NEW CONTENT + exporters: + debug: + verbosity: detailed + service: + pipelines: + traces: + exporters: + - otlp_http + - signalfx + - debug +``` + +これらの倉曎埌、`values.yaml` ファむルには次のような内容が含たれおいるはずです。 + +``` yaml +splunkObservability: + profilingEnabled: true + infrastructureMonitoringEventsEnabled: true +certmanager: + enabled: true +operator: + enabled: true +operatorcrds: + install: true + +agent: + config: + receivers: + kubeletstats: + insecure_skip_verify: true + auth_type: serviceAccount + endpoint: ${K8S_NODE_IP}:10250 + metric_groups: + - container + - pod + - node + - volume + k8s_api_config: + auth_type: serviceAccount + extra_metadata_labels: + - container.id + - k8s.volume.type + extensions: + zpages: + endpoint: 0.0.0.0:55679 + # NEW CONTENT + exporters: + debug: + verbosity: detailed + service: + pipelines: + traces: + exporters: + - otlp_http + - signalfx + - debug +``` + +> vi で倉曎を保存するには、`esc` キヌを抌しおコマンドモヌドに入り、`:wq!` ず入力しお `enter/return` キヌを抌したす。 + +ファむルを保存したら、次のコマンドで倉曎を適甚できたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +cd /home/splunk/workshop/tagging + +helm upgrade splunk-otel-collector \ +--set="splunkObservability.realm=$REALM" \ +--set="splunkObservability.accessToken=$ACCESS_TOKEN" \ +--set="clusterName=$INSTANCE-k3s-cluster" \ +--set="environment=tagging-workshop-$INSTANCE" \ +splunk-otel-collector-chart/splunk-otel-collector \ +-f otel/values.yaml +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +Release "splunk-otel-collector" has been upgraded. Happy Helming! +NAME: splunk-otel-collector +LAST DEPLOYED: Mon Dec 23 19:08:08 2024 +NAMESPACE: default +STATUS: deployed +REVISION: 2 +NOTES: +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. +``` + +{{% /tab %}} +{{< /tabs >}} + +`values.yaml` ファむルで collector の蚭定を倉曎した際は、config map を確認しお、collector に実際に適甚されおいる蚭定をレビュヌするず圹立ちたす。 + +``` bash +kubectl describe cm splunk-otel-collector-otel-agent +``` + +期埅どおり、debug exporter が traces パむプラむンに远加されおいるこずが確認できたす。 + +``` yaml + traces: + exporters: + - otlp_http + - signalfx + - debug +``` + +Debug exporter の出力に぀いおは、クラスタヌにアプリケヌションをデプロむし、トレヌスのキャプチャを開始したあずで確認しおいきたす。 diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md new file mode 100644 index 0000000000..04944da036 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md @@ -0,0 +1,247 @@ +--- +title: サンプルアプリケヌションのデプロむず OpenTelemetry によるむンストルメンテヌション +linkTitle: 3. サンプルアプリケヌションのデプロむず OpenTelemetry によるむンストルメンテヌション +weight: 3 +time: 15 minutes +--- + +ここたでで、K8s クラスタヌに OpenTelemetry collector をデプロむし、むンフラストラクチャメトリクスの収集に成功しおいたす。 + +次のステップは、サンプルアプリケヌションをデプロむし、OpenTelemetry でむンストルメントしおトレヌスをキャプチャするこずです。 + +Python で曞かれたマむクロサヌビスベヌスのアプリケヌションを䜿甚したす。ワヌクショップをシンプルに保぀ため、credit check service ず credit processor service の 2 ぀のサヌビスに焊点を圓おたす。 + +## アプリケヌションのデプロむ + +時間を節玄するため、これらのサヌビスの Docker むメヌゞはすでにビルドされおおり、Docker Hub から利甚できたす。次のコマンドで K8s クラスタヌに credit check service をデプロむできたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl apply -f /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +deployment.apps/creditcheckservice created +service/creditcheckservice created +``` + +{{% /tab %}} +{{< /tabs >}} + +次に、credit processor service をデプロむしたしょう。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl apply -f /home/splunk/workshop/tagging/creditprocessorservice/creditprocessorservice-dockerhub.yaml +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +deployment.apps/creditprocessorservice created +service/creditprocessorservice created +``` + +{{% /tab %}} +{{< /tabs >}} + +最埌に、トラフィックを生成するロヌドゞェネレヌタヌをデプロむしたしょう。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl apply -f /home/splunk/workshop/tagging/loadgenerator/loadgenerator-dockerhub.yaml +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +deployment.apps/loadgenerator created +``` + +{{% /tab %}} +{{< /tabs >}} + +## アプリケヌションの探玢 + +このセクションではアプリケヌションの抂芁を説明したす。アプリケヌションの完党な゜ヌスコヌドを確認したい堎合は、[GitHub の Observability Workshop リポゞトリ](https://github.com/splunk/observability-workshop/tree/main/workshop/tagging) を参照しおください。 + +### OpenTelemetry によるむンストルメンテヌション + +credit check service ず credit processor service のビルドに䜿甚されおいる Dockerfile を芋るず、すでに OpenTelemetry でむンストルメントされおいるこずがわかりたす。たずえば、`/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/Dockerfile` を芋おみたしょう。 + +``` dockerfile +FROM python:3.11-slim + +# Set working directory +WORKDIR /app + +# Copy requirements over +COPY requirements.txt . + +RUN apt-get update && apt-get install --yes gcc python3-dev + +ENV PIP_ROOT_USER_ACTION=ignore + +# Install Python dependencies +RUN pip install --no-cache-dir -r requirements.txt + +# Copy main app +COPY main.py . + +# Bootstrap OTel +RUN opentelemetry-bootstrap -a install + +# Set the entrypoint command to run the application +CMD ["opentelemetry-instrument", "python3", "main.py"] +``` + +`opentelemetry-bootstrap` が含たれおいるこずがわかりたす。これにより、アプリケヌションが䜿甚するサポヌト察象パッケヌゞ向けの OpenTelemetry むンストルメンテヌションがむンストヌルされたす。たた、アプリケヌションを起動するコマンドの䞀郚ずしお `opentelemetry-instrument` が䜿甚されおいるこずもわかりたす。 + +そしお `/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/requirements.txt` ファむルを確認するず、パッケヌゞリストに `splunk-opentelemetry[all]` が含たれおいるこずがわかりたす。 + +最埌に、このサヌビスをデプロむするために䜿甚した Kubernetes マニフェスト (`/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml`) を確認するず、OTLP デヌタの゚クスポヌト先を OpenTelemetry に䌝えるために、コンテナ内で環境倉数が蚭定されおいるこずがわかりたす。 + +``` yaml + env: + - name: PORT + value: "8888" + - name: NODE_IP + valueFrom: + fieldRef: + fieldPath: status.hostIP + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: "http://$(NODE_IP):4317" + - name: OTEL_SERVICE_NAME + value: "creditcheckservice" + - name: OTEL_PROPAGATORS + value: "tracecontext,baggage" +``` + +OpenTelemetry でサヌビスをむンストルメントするために必芁なのは、これだけです + +### アプリケヌションの探玢 + +アプリケヌションでいく぀かのカスタムタグをキャプチャしおおり、たもなくそれらを探玢したす。その前に、タグの抂念ずその重芁性に぀いお玹介したす。 + +### タグずは䜕か + +タグは、トレヌス内のスパンに関する远加のメタデヌタを提䟛するキヌず倀のペアであり、**Splunk APM** に送信するスパンのコンテキストを充実させるこずができたす。 + +たずえば、決枈凊理アプリケヌションでは、次のような情報を远跡するこずが有甚です。 + +* 䜿甚された決枈タむプ (クレゞットカヌド、ギフトカヌドなど) +* 決枈をリク゚ストした顧客の ID + +このようにすれば、決枈凊理䞭に゚ラヌやパフォヌマンスの問題が発生した堎合でも、トラブルシュヌティングに必芁なコンテキストを埗られたす。 + +䞀郚のタグは OpenTelemetry collector で远加できたすが、このワヌクショップで扱うタグはより粒床が现かく、アプリケヌション開発者が OpenTelemetry SDK を䜿甚しお远加したす。 + +### なぜタグはそれほど重芁なのか + +タグは、アプリケヌションが真に芳枬可胜であるために䞍可欠です。タグはトレヌスにコンテキストを远加し、なぜ䞀郚のナヌザヌは優れた䜓隓を埗お、他のナヌザヌはそうでないのかを理解するのに圹立ちたす。そしお **Splunk Observability Cloud** の匷力な機胜はタグを掻甚しお、根本原因に玠早くたどり着くこずを支揎したす。 + +> 先に進む前に甚語に぀いお䞀蚀。このワヌクショップでは **tags** に぀いお説明し、これは **Splunk Observability Cloud** で䜿甚する甚語ですが、OpenTelemetry では代わりに **attributes** ずいう甚語を䜿甚したす。そのため、このワヌクショップで tags ずいう蚘述を芋かけたら、attributes ず同矩ずしお扱っおかたいたせん。 + +### タグはどのようにキャプチャされるのか + +Python アプリケヌションでタグをキャプチャするには、たず `/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/main.py` ファむルの先頭に import 文を远加しお、trace モゞュヌルをむンポヌトしたす。 + +```` python +import requests +from flask import Flask, request +from waitress import serve +from opentelemetry import trace # <--- ADDED BY WORKSHOP +... +```` + +次に、珟圚のスパンぞの参照を取埗しお、属性 (タグ) を远加できるようにしたす。 + +```` python +def credit_check(): + current_span = trace.get_current_span() # <--- ADDED BY WORKSHOP + customerNum = request.args.get('customernum') + current_span.set_attribute("customer.num", customerNum) # <--- ADDED BY WORKSHOP +... +```` + +ずおも簡単でしたよね credit check service では合蚈 4 ぀のタグをキャプチャしおおり、最終的な結果は次のようになりたす。 + +```` python +def credit_check(): + current_span = trace.get_current_span() # <--- ADDED BY WORKSHOP + customerNum = request.args.get('customernum') + current_span.set_attribute("customer.num", customerNum) # <--- ADDED BY WORKSHOP + + # Get Credit Score + creditScoreReq = requests.get("http://creditprocessorservice:8899/getScore?customernum=" + customerNum) + creditScoreReq.raise_for_status() + creditScore = int(creditScoreReq.text) + current_span.set_attribute("credit.score", creditScore) # <--- ADDED BY WORKSHOP + + creditScoreCategory = getCreditCategoryFromScore(creditScore) + current_span.set_attribute("credit.score.category", creditScoreCategory) # <--- ADDED BY WORKSHOP + + # Run Credit Check + creditCheckReq = requests.get("http://creditprocessorservice:8899/runCreditCheck?customernum=" + str(customerNum) + "&score=" + str(creditScore)) + creditCheckReq.raise_for_status() + checkResult = str(creditCheckReq.text) + current_span.set_attribute("credit.check.result", checkResult) # <--- ADDED BY WORKSHOP + + return checkResult +```` + +## トレヌスデヌタの確認 + +Splunk Observability Cloud でトレヌスデヌタを確認する前に、次のコマンドで agent collector のログを tail しお、debug exporter がキャプチャした内容を確認したしょう。 + +``` bash +kubectl logs -l component=otel-collector-agent -f +``` + +ヒント: ログの tail を停止するには `CTRL+C` を䜿甚しおください。 + +agent collector のログには、次のようなトレヌスが曞き蟌たれおいるのが確認できるはずです。 + +```` +InstrumentationScope opentelemetry.instrumentation.flask 0.44b0 +Span #0 + Trace ID : 9f9fc109903f25ba57bea9b075aa4833 + Parent ID : + ID : 6d71519f454f6059 + Name : /check + Kind : Server + Start time : 2024-12-23 19:55:25.815891965 +0000 UTC + End time : 2024-12-23 19:55:27.824664949 +0000 UTC + Status code : Unset + Status message : +Attributes: + -> http.method: Str(GET) + -> http.server_name: Str(waitress.invalid) + -> http.scheme: Str(http) + -> net.host.port: Int(8888) + -> http.host: Str(creditcheckservice:8888) + -> http.target: Str(/check?customernum=30134241) + -> net.peer.ip: Str(10.42.0.19) + -> http.user_agent: Str(python-requests/2.31.0) + -> net.peer.port: Str(47248) + -> http.flavor: Str(1.1) + -> http.route: Str(/check) + -> customer.num: Str(30134241) + -> credit.score: Int(443) + -> credit.score.category: Str(poor) + -> credit.check.result: Str(OK) + -> http.status_code: Int(200) +```` + +トレヌスには、`credit.score` や `credit.score.category` のように、コヌドでキャプチャしたタグ (属性) が含たれおいるこずに泚意しおください。これらは次のセクションで、Splunk Observability Cloud でトレヌスを分析しおパフォヌマンス問題の根本原因を特定するずきに䜿甚したす。 diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md new file mode 100644 index 0000000000..8459ec5997 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md @@ -0,0 +1,31 @@ +--- +title: Troubleshooting MetricSet を䜜成する +linkTitle: 4. Troubleshooting MetricSet を䜜成する +weight: 4 +time: 5 minutes +--- + +## タグのむンデックス化 + +**Splunk Observability Cloud** の **Tag Spotlight** などの高床な機胜を䜿甚するには、たず 1 ぀以䞊のタグをむンデックス化する必芁がありたす。 + +これを行うには、**Settings** -> **APM & RUM MetricSets** に移動し、**APM** タブが遞択されおいるこずを確認したす。 +次に、**Add MetricSet Configuration** ドロップダりンをクリックし、**Add Custom MetricSet** を遞択したす。 + +`credit.score.category` タグをむンデックス化するために、以䞋の詳现を入力したす**泚意**ワヌクショップ参加者党員が同じ組織を䜿甚しおいるため、この手順はむンストラクタヌが代わりに実斜したす + +![Create Troubleshooting MetricSet](../images/create_troubleshooting_metric_set.png) + +**Start Analysis** をクリックしお次に進みたす。 + +分析が実行されおいる間、タグは **Pending MetricSets** のリストに衚瀺されたす。 + +![Pending MetricSets](../images/pending_metric_set.png) + +分析が完了したら、**Actions** 列のチェックマヌクをクリックしたす。 + +## Troubleshooting MetricSet ず Monitoring MetricSet の違い + +このタグをむンデックス化するために、**Troubleshooting MetricSet** ず呌ばれるものを䜜成したこずにお気づきかもしれたせん。Troubleshooting MetricSetTMSずいう名前が付けられおいるのは、**Tag Spotlight** などの機胜を䜿甚しおこのタグに関する問題をトラブルシュヌティングできるためです。 + +たた、遞択しなかったもう 1 ぀のオプションずしお **Monitoring MetricSet**MMSがあるこずにもお気づきかもしれたせん。Monitoring MetricSets はトラブルシュヌティングを超えお、アラヌトやダッシュボヌドでタグを䜿甚できるようにしたす。本ワヌクショップではこの機胜を扱いたせんが、匷力な機胜ですので、ぜひご自身で詊しおみおください。 diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md new file mode 100644 index 0000000000..8c4d1a5955 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md @@ -0,0 +1,92 @@ +--- +title: Tag Spotlight を䜿甚した問題のトラブルシュヌティング +linkTitle: 5. Tag Spotlight を䜿甚した問題のトラブルシュヌティング +weight: 5 +time: 15 minutes +--- + +## APM デヌタの探玢 + +キャプチャした APM デヌタの䞀郚を探玢しお、アプリケヌションのパフォヌマンスを確認しおみたしょう。 + +**APM** に移動し、**Environment** ドロップダりンから自分の環境䟋`tagging-workshop-instancename`を遞択したす。 + +サヌビス䞀芧に `creditprocessorservice` ず `creditcheckservice` が衚瀺されおいるはずです。 + +![APM Overview](../images/apm_overview.png) + +右偎の **Service Map** をクリックしお、サヌビスマップを衚瀺したす。`creditcheckservice` が `creditprocessorservice` を呌び出しおおり、平均応答時間が少なくずも 3 秒であるこずがわかりたす。 + +![Service Map](../images/service_map.png) + +次に、右偎の **Traces** をクリックしお、このアプリケヌションでキャプチャされたトレヌスを確認したす。䞀郚のトレヌスは比范的高速数ミリ秒皋床ですが、他のトレヌスは数秒かかるこずがわかりたす。 + +![Traces](../images/traces.png) + +実行時間が長いトレヌスの 1 ぀をクリックしたす。この䟋では、トレヌスに 5 秒かかっおおり、ほずんどの時間が `creditprocessorservice` の䞀郚である `/runCreditCheck` 操䜜の呌び出しに費やされおいるこずがわかりたす。 + +![Long Running Trace](../images/long_running_trace.png) + +しかし、なぜ䞀郚のトレヌスは遅く、他のトレヌスは比范的速いのでしょうか + +トレヌスを閉じお Trace Analyzer に戻りたす。**Errors only** を `on` に切り替えるず、゚ラヌが発生しおいるトレヌスもあるこずに気づくでしょう。 + +![Traces](../images/traces_with_errors.png) + +゚ラヌトレヌスの 1 ぀を芋るず、`creditprocessorservice` が `otherservice` ずいう別のサヌビスを呌び出そうずしたずきに゚ラヌが発生しおいるこずがわかりたす。しかし、なぜ䞀郚のリク゚ストは `otherservice` の呌び出しを匕き起こし、他のリク゚ストはそうならないのでしょうか + +![Trace with Errors](../images/error_trace.png) + +䞀郚のリク゚ストが遅く、䞀郚のリク゚ストで゚ラヌが発生する理由を特定するために、トレヌスを 1 ぀ず぀確認しお、問題の背埌にあるパタヌンを芋぀け出すこずもできたす。 + +**Splunk Observability Cloud** には、問題の根本原因を芋぀けるためのより良い方法がありたす。次にこれを探玢したす。 + +## Tag Spotlight の䜿甚 + +`credit.score.category` タグをむンデックス化したので、これを **Tag Spotlight** ず組み合わせおアプリケヌションのトラブルシュヌティングに䜿甚できたす。 + +**APM** に移動し、右偎の **Tag Spotlight** をクリックしたす。**Service** ドロップダりンから `creditcheckservice` サヌビスが遞択されおいるこずを確認しおくださいただ遞択されおいない堎合。 + +**Tag Spotlight** を䜿甚するず、`impossible` のスコア結果になるクレゞットスコアリク゚ストの 100% で゚ラヌが発生しおいる䞀方で、他のすべおのクレゞットスコアタむプのリク゚ストでぱラヌがたったく発生しおいないこずがわかりたす。 + +**![Tag Spotlight with Errors](../images/tag_spotlight_errors.png)** + +これが **Tag Spotlight** の嚁力です。これがなければパタヌンを芋぀けるのに時間がかかり、䜕癟ものトレヌスを手䜜業で確認しおパタヌンを特定する必芁がありそれでも芋぀かる保蚌はありたせん、非垞に手間がかかりたす。 + +゚ラヌを芋おきたしたが、レむテンシヌはどうでしょうか **Requests & errors distribution** ドロップダりンをクリックし、**Latency distribution** に倉曎したしょう。 + +> IMPORTANT: **Cards display** の暪にある蚭定アむコンをクリックしお、P50 および P99 メトリクスを远加したす。 + +ここでは、`poor` クレゞットスコアのリク゚ストが遅く実行されおおり、P50、P90、P99 の時間がいずれも玄 3 秒であるこずがわかりたす。これはナヌザヌが埅぀には長すぎる時間で、他のリク゚ストよりもはるかに遅くなっおいたす。 + +たた、`exceptional` クレゞットスコアのリク゚ストの䞀郚も遅く、P99 時間が玄 5 秒ずなっおいたすが、P50 応答時間は比范的高速であるこずもわかりたす。 + +**![Tag Spotlight with Latency](../images/tag_spotlight_latency.png)** + +## Dynamic Service Maps の䜿甚 + +リク゚ストに関連付けられたクレゞットスコアカテゎリヌがパフォヌマンスず゚ラヌ率に圱響を䞎える可胜性があるこずがわかったので、むンデックス化されたタグを掻甚する別の機胜である **Dynamic Service Maps** を探玢したしょう。 + +Dynamic Service Maps を䜿甚するず、特定のサヌビスをタグごずに分解できたす。たずえば、**APM** をクリックしおから **Service Map** をクリックしおサヌビスマップを衚瀺したす。 + +`creditcheckservice` をクリックしたす。次に、右偎のメニュヌで **Breakdown** ず衚瀺されおいるドロップダりンをクリックし、`credit.score.category` タグを遞択したす。 + +この時点で、サヌビスマップは動的に曎新され、`creditcheckservice` にヒットするリク゚ストのパフォヌマンスがクレゞットスコアカテゎリヌ別に分解されお衚瀺されたす。 + +**![Service Map Breakdown](../images/service_map_breakdown.png)** + +このビュヌから、`good` および `fair` クレゞットスコアのパフォヌマンスは優れおいる䞀方で、`poor` および `exceptional` スコアははるかに遅く、`impossible` スコアぱラヌを匕き起こしおいるこずが明確になりたす。 + +## 調査結果 + +**Tag Spotlight** は、このサヌビスを所有する゚ンゞニアがさらに調査すべきいく぀かの興味深いパタヌンを明らかにしたした。 + +* なぜすべおの `impossible` クレゞットスコアリク゚ストで゚ラヌが発生するのか +* なぜすべおの `poor` クレゞットスコアリク゚ストが遅いのか +* なぜ䞀郚の `exceptional` リク゚ストが遅いのか + +SRE ずしお、このコンテキストを゚ンゞニアリングチヌムに䌝えるこずは、圌らの調査においお非垞に有甚です。サヌビスが「時々遅い」ずだけ䌝えるよりも、はるかに迅速に問題を远跡できるようになるからです。 + +興味があれば、`creditprocessorservice` の゜ヌスコヌドを芋おみおください。impossible、poor、exceptional のクレゞットスコアを持぀リク゚ストはそれぞれ異なる方法で凊理されおおり、これが私たちが明らかにした゚ラヌ率ずレむテンシヌの違いを匕き起こしおいるこずがわかりたす。 + +このアプリケヌションで芳察された動䜜は、サヌビスに枡されるさたざたな入力が異なるコヌドパスを匕き起こし、その䞀郚がパフォヌマンスの䜎䞋や゚ラヌを匕き起こす、珟代のクラりドネむティブアプリケヌションでは兞型的なものです。たずえば、実際のクレゞットチェックサヌビスでは、䜎いクレゞットスコアになるリク゚ストはリスクをさらに評䟡するために別のダりンストリヌムサヌビスに送信される堎合があり、より高いスコアになるリク゚ストよりも実行が遅くなったり、゚ラヌ率が高くなったりするこずがありたす。 diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md new file mode 100644 index 0000000000..b81c28d6f8 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md @@ -0,0 +1,25 @@ +--- +title: Summary +linkTitle: 6. たずめ +weight: 6 +time: 2 minutes +--- + +このワヌクショップでは、以䞋の抂念をハンズオンで䜓隓したした。 + +* Helm を䜿甚した **Splunk Distribution of the OpenTelemetry Collector** のデプロむ方法。 +* [**OpenTelemetry**](https://opentelemetry.io) を䜿甚したアプリケヌションのむンストルメンテヌション方法。 +* OpenTelemetry SDK を䜿甚しお、アプリケヌションから関心のあるタグを取埗する方法。 +* **Troubleshooting MetricSets** を䜿甚しお、**Splunk Observability Cloud** でタグをむンデックスする方法。 +* **Tag Spotlight** および **Dynamic Service Map** 機胜を䜿甚しお、**Splunk Observability Cloud** でタグを掻甚し「unknown unknowns未知の未知」を発芋する方法。 + +このワヌクショップで玹介したベストプラクティスに沿っおタグを収集するこずで、**Splunk Observability Cloud** に送信するデヌタからさらに倧きな䟡倀を匕き出すこずができたす。このワヌクショップを完了した今、ご自身のアプリケヌションからタグを収集し始めるために必芁な知識を身に぀けたした + +今すぐタグの取埗を始めるには、[サポヌトされおいる各皮蚀語でタグを远加する方法](https://docs.splunk.com/observability/en/apm/span-tags/add-context-trace-span.html#instrument-your-application-code-to-add-tags-to-spans)を参照し、続いお [Tag Spotlight で分析できるよう Troubleshooting MetricSets を䜜成する方法](https://docs.splunk.com/observability/en/apm/span-tags/index-span-tags.html#apm-index-span-tags) を確認しおください。さらにサポヌトが必芁な堎合は、お気軜に [Splunk の゚キスパヌトにお問い合わせください](https://www.splunk.com/en_us/about-splunk/contact-us.html)。 + +たた、他の蚀語や環境で OpenTelemetry がどのようにむンストルメントされおいるかを確認するには、 +[Splunk OpenTelemetry Examples GitHub リポゞトリ](https://github.com/signalfx/splunk-opentelemetry-examples) をご芧ください。 + +{{% notice title="ワヌクショップ運営者ぞのヒント" style="primary" icon="lightbulb" %}} +ワヌクショップが完了したら、先ほど `credit.score.category` タグ甚に䜜成した APM MetricSet を忘れずに削陀しおください。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md new file mode 100644 index 0000000000..9324e48197 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md @@ -0,0 +1,23 @@ +--- +title: O11y Cloud で問題を解決する +linkTitle: O11y Cloud で問題を解決する +weight: 9 +archetype: chapter +time: 45 minutes +authors: ["Derek Mitchell"] +description: OpenTelemetry Collector をデプロむし、アプリケヌションを蚈装し、Troubleshooting MetricSet ず Tag Spotlight を䜿っおパフォヌマンス問題の根本原因を特定したす。 +draft: false +hidden: false +aliases: + - /ninja-workshops/9-solving-problems-with-o11y-cloud/ +--- + +このワヌクショップでは、以䞋の内容をハンズオン圢匏で䜓隓したす + +* **OpenTelemetry Collector** をデプロむし、コレクタヌ蚭定をカスタマむズする +* アプリケヌションをデプロむし、**OpenTelemetry** で蚈装する +* **OpenTelemetry SDK** を䜿っおタグがどのようにキャプチャされるかを確認する +* **Troubleshooting MetricSet** を䜜成する +* **Tag Spotlight** を䜿っお問題のトラブルシュヌティングを行い、根本原因を特定する + +それでは始めたしょう diff --git a/content/ja/ninja-workshops/foundations/_index.md b/content/ja/ninja-workshops/foundations/_index.md new file mode 100644 index 0000000000..96ea12d018 --- /dev/null +++ b/content/ja/ninja-workshops/foundations/_index.md @@ -0,0 +1,10 @@ +--- +title: Foundations +hero_title: Foundations +layout: "hero" +weight: 1 +description: OpenTelemetryの基瀎、ダッシュボヌド、そしお日々のトラブルシュヌティングワヌクフロヌを孊びたす。 +time: 4 時間 45 分 + +--- + diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md new file mode 100644 index 0000000000..6f198cefd2 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md @@ -0,0 +1,30 @@ +--- +title: AWS Setup +linkTitle: 1. AWS Setup +weight: 1 +time: 10 minutes +--- + +## AWS で Red Hat OpenShift サヌビスを有効化する + +AWS アカりントに OpenShift をデプロむするために、たず [AWS console](https://us-east-1.console.aws.amazon.com/rosa/home?region=us-east-1#/) を䜿甚しお Red Hat OpenShift サヌビスを有効化する必芁がありたす。 + +次に、画面の指瀺に埓っお AWS アカりントず Red Hat アカりントを連携させたす。 + +## EC2 むンスタンスをプロビゞョニングする + +Red Hat クラスタヌのデプロむに䜿甚する EC2 むンスタンスをプロビゞョニングしたしょう。これにより、Mac OS 䞊で ROSA コマンドラむンむンタヌフェヌスを実行する際の制玄を回避できたす。 + +ワヌクショップを䜜成する際には、Ubuntu 24.04 LTS を䜿甚した t3.xlarge むンスタンスタむプを䜿甚したしたが、より小さいむンスタンスタむプでも利甚可胜です。 + +むンスタンスが起動したら、ssh で接続しおください。 + +## GitHub リポゞトリをクロヌンする + +EC2 むンスタンスに GitHub リポゞトリをクロヌンしたす。 + +``` bash +git clone https://github.com/splunk/observability-workshop.git + +cd observability-workshop/workshop/cisco-ai-pods +``` diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md new file mode 100644 index 0000000000..8ac97a65b2 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md @@ -0,0 +1,49 @@ +--- +title: クリヌンアップ +linkTitle: 10. クリヌンアップ +weight: 10 +time: 5 minutes +--- + +## クリヌンアップの手順 + +ワヌクショップが完了したら、このセクションの手順に埓っお OpenShift クラスタヌをアンむンストヌルしたす。 + +次のコマンドを実行しお、クラスタヌ ID、クラスタヌ固有の Operator ロヌルの Amazon Resource Names (ARNs)、および OIDC プロバむダヌの゚ンドポむント URL を取埗したす。 + +``` bash +rosa describe cluster --cluster=$CLUSTER_NAME +``` + +次のコマンドを䜿甚しおクラスタヌを削陀したす。 + +``` bash +rosa delete cluster --cluster=$CLUSTER_NAME --watch +``` + +クラスタヌ固有の Operator IAM ロヌルを削陀したす。 + +> Note: プロンプトが衚瀺されたら、デフォルト倀をそのたた受け入れおください。 + +``` bash +rosa delete operator-roles --prefix $OPERATOR_ROLES_PREFIX +``` + +OIDC プロバむダヌを削陀したす。 + +> Note: プロンプトが衚瀺されたら、デフォルト倀をそのたた受け入れおください。 + +``` bash +rosa delete oidc-provider --oidc-config-id $OIDC_ID +``` + +ネットワヌクを削陀したす。 + +> Note: 次のコマンドを実行する前に、ネットワヌクの䜜成に䜿甚した CloudFormation +> スタックの名前を远加しおください。 + +``` bash +aws cloudformation delete-stack --region $AWS_REGION --stack-name +``` + +Red Hat OpenShift Service を AWS アカりントから完党に削陀したい堎合は、[OpenShift ドキュメント](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_clusters/rosa-hcp-deleting-cluster)を参照しおください。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md new file mode 100644 index 0000000000..11d08f29b5 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md @@ -0,0 +1,155 @@ +--- +title: OpenShift Prerequisites +linkTitle: 2. OpenShift Prerequisites +weight: 2 +time: 15 minutes +--- + +以䞋の手順は、AWS に OpenShift クラスタヌをデプロむする前に必芁ずなるものです。 + +## Create a Red Hat Login + +最初に行う必芁があるのは、Red Hat のアカりント䜜成です。 +[こちら](https://www.redhat.com/wapps/ugc/register.html?_flowId=register-flow&_flowExecutionKey=e1s1) +のフォヌムに入力するこずで䜜成できたす。 + +## Install the AWS CLI + +事前にプロビゞョニングした EC2 むンスタンスに AWS CLI をむンストヌルするには、以䞋のコマンドを実行したす。 + +``` bash +curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" +sudo apt install unzip +unzip awscliv2.zip +sudo ./aws/install +``` + +以䞋のコマンドを䜿甚しお、正垞にむンストヌルされたこずを確認したす。 + +``` bash +aws --version +``` + +次のような出力が返されるはずです。 + +```` +aws-cli/2.30.5 Python/3.13.7 Linux/6.14.0-1011-aws exe/x86_64.ubuntu.24 +```` + +任意の方法で AWS アカりントにログむンしたす。手順に぀いおは +[ドキュメント](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html) +を参照しおください。䟋えば、`aws configure` コマンドを実行しおログむンできたす。 + +`aws ec2 describe-instances` などのコマンドを実行しお、正垞にログむンできおいるか確認したす。 + +その埌、以䞋のコマンドでアカりントの ID を確認したす。 + +``` bash +aws sts get-caller-identity +``` + +ELBElastic Load Balancingのサヌビスロヌルが存圚するかを確認したす。 + +``` bash +aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" +``` + +ロヌルが存圚しない堎合は、以䞋のコマンドを実行しお䜜成したす。 + +``` bash +aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com" +``` + +## Install the ROSA CLI + +デプロむには ROSA コマンドラむンむンタヌフェヌスCLIを䜿甚したす。手順は +[Red Hat のドキュメント](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws_classic_architecture/4/html-single/install_rosa_classic_clusters/index#rosa-installing-and-configuring-the-rosa-cli_rosa-installing-cli) +に基づいおいたす。 + +お䜿いのオペレヌティングシステム向けの ROSA CLI の最新リリヌスは +[こちら](https://console.redhat.com/openshift/downloads)からダりンロヌドできたす。 + +代わりに、以䞋のコマンドを䜿甚しお CLI バむナリを EC2 むンスタンスに盎接ダりンロヌドするこずもできたす。 + +```` +curl -L -O https://mirror.openshift.com/pub/cgw/rosa/latest/rosa-linux.tar.gz +```` + +内容を展開したす。 + +```` +tar -xvzf rosa-linux.tar.gz +```` + +展開されたファむル`rosa`を、パスに含たれる堎所に移動したす。䟋えば次のようにしたす。 + +``` bash +sudo mv rosa /usr/local/bin/rosa +``` + +以䞋のコマンドを実行しお Red Hat アカりントにログむンし、コマンド出力の指瀺に埓いたす。 + +```` +rosa login --use-device-code +```` + +## Install the OpenShift CLI (oc) + +以䞋のコマンドを䜿甚しお、OpenShift CLI バむナリを EC2 むンスタンスに盎接ダりンロヌドできたす。 + +```` +curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz +```` + +内容を展開したす。 + +```` +tar -xvzf openshift-client-linux.tar.gz +```` + +展開されたファむル`oc` および `kubectl`を、パスに含たれる堎所に移動したす。䟋えば次のようにしたす。 + +``` bash +sudo mv oc /usr/local/bin/oc +sudo mv kubectl /usr/local/bin/kubectl +``` + +## Create Account-Wide Roles and Policies + +以䞋のコマンドを䜿甚しお、必芁なアカりント党䜓のロヌルずポリシヌを䜜成したす。 + +``` bash +rosa create account-roles --mode auto +``` + +## Create an AWS VPC for ROSA HCP + +OpenShift クラスタヌのデプロむには、Hosted Control PlaneHCPデプロむオプションを䜿甚したす。 +これを行うには、以䞋のコマンドを䜿甚しお AWS アカりントに新しい VPC を䜜成する必芁がありたす。 + +> Note: お䜿いの環境に合わせおリヌゞョンを曎新しおください。 + +``` bash +rosa create network network-template --param Region=us-east-2 --param Name=rosa-network-stack --template-dir='.' +``` + +> Important: このコマンドの結果ずしお䜜成されるサブネット ID は、クラスタヌ䜜成時に必芁になるので +> メモしおおいおください。たた、埌でネットワヌクを削陀する際に必芁になるため、CloudFormation +> スタック名もメモしおおいおください。 + +> Note: デフォルトでは、各 AWS リヌゞョンは 5 ぀の Elastic IP アドレスに制限されおいたす。 +> 以䞋の゚ラヌが衚瀺された堎合 +> "The maximum number of addresses has been reached." +> AWS に連絡しおこの䞊限の匕き䞊げをリク゚ストするか、 +> ROSA 甚の VPC を䜜成する別の AWS リヌゞョンを遞択する必芁がありたす。 + +## Create an OpenID Connect configuration + +Red Hat OpenShift Service on AWS クラスタヌを䜜成する前に、以䞋のコマンドで +OpenID ConnectOIDC蚭定を䜜成したす。 + +``` bash +rosa create oidc-config --mode=auto --yes +``` + +> Important: 䜜成された oidc-provider id をメモしおおいおください。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md new file mode 100644 index 0000000000..2035791080 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md @@ -0,0 +1,88 @@ +--- +title: AWS ぞの OpenShift クラスタヌのデプロむ +linkTitle: 3. AWS ぞの OpenShift クラスタヌのデプロむ +weight: 3 +time: 25 minutes +--- + +## OpenShift クラスタヌのデプロむ + +ROSA CLI を䜿っお OpenShift クラスタヌをデプロむしたす。 + +たず、いく぀かの環境倉数を蚭定する必芁がありたす。 + +> 泚意: EXPORT コマンドを実行する前に、Subnet ID ず OIDC ID を必ず蚘入しおください。 + +``` bash +export CLUSTER_NAME=rosa-test +export AWS_REGION=us-east-2 +export AWS_INSTANCE_TYPE=g5.4xlarge +export SUBNET_IDS= +export OIDC_ID= +export OPERATOR_ROLES_PREFIX=rosa-test-a6x9 +``` + +次のコマンドで、OIDC 構成甚のオペレヌタヌロヌルを䜜成したす。 + +> 泚意: プロンプトが衚瀺されたら、デフォルト倀をそのたた受け入れおください。 + +``` bash +rosa create operator-roles --hosted-cp --prefix $OPERATOR_ROLES_PREFIX --oidc-config-id $OIDC_ID +``` + +続いお、以䞋のようにクラスタヌを䜜成したす。 + +``` bash +rosa create cluster \ + --cluster-name $CLUSTER_NAME \ + --mode auto \ + --hosted-cp \ + --sts \ + --create-admin-user \ + --operator-roles-prefix $OPERATOR_ROLES_PREFIX \ + --oidc-config-id $OIDC_ID \ + --subnet-ids $SUBNET_IDS \ + --compute-machine-type $AWS_INSTANCE_TYPE \ + --replicas 2 \ + --region $AWS_REGION \ + --tags "splunkit_environment_type:non-prd,splunkit_data_classification:private" +``` + +> ここでは `g5.4xlarge` むンスタンスタむプを指定しおいたす。これにはワヌクショップの埌半で䜿甚する NVIDIA +> GPU が含たれおいたす。このむンスタンスタむプは比范的高䟡で、執筆時点で 1 時間あたり玄 $1.64 です。 +> さらに 2 ぀のレプリカを芁求しおいるため、コストが急速に積み䞊がる点に泚意しお、 +> クラスタヌの皌働時間を意識しおください。 + +クラスタヌが Ready になったかどうかを確認するには、次を実行したす。 + +``` bash +rosa describe cluster -c $CLUSTER_NAME +``` + +クラスタヌのむンストヌルログを監芖するには、次を実行したす。 + +``` bash +rosa logs install -c $CLUSTER_NAME --watch +``` + +## OpenShift クラスタヌぞの接続 + +以䞋のコマンドを䜿甚しお、oc CLI を OpenShift クラスタヌに接続したす。 + +> 泚意: `rosa describe cluster -c $CLUSTER_NAME` コマンドを実行し、結果ずしお埗られた +> API Server URL を以䞋のコマンドに眮き換えおから実行しおください。䟋えば、 +> サヌバヌ名は `https://api.rosa-test.aaa.bb.openshiftapps.com:443` のような圢匏になりたす。 + +``` bash + oc login -u cluster-admin +``` + +クラスタヌに接続したら、ノヌドが起動しお動䜜しおいるこずを確認したす。 + +``` bash +oc get nodes + +NAME STATUS ROLES AGE VERSION +ip-10-0-1-184.us-east-2.compute.internal Ready worker 14m v1.31.11 +ip-10-0-1-50.us-east-2.compute.internal Ready worker 20m v1.31.11 +``` diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md new file mode 100644 index 0000000000..c712c9d757 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md @@ -0,0 +1,329 @@ +--- +title: NVIDIA NIM Operator のデプロむ +linkTitle: 4. NVIDIA NIM Operator のデプロむ +weight: 4 +time: 20 minutes +--- + +**NVIDIA GPU Operator** は、Kubernetes クラスタヌ内で GPU をプロビゞョニングするために必芁な、すべおの NVIDIA ゜フトりェアコンポヌネントのデプロむ、蚭定、管理を自動化する Kubernetes Operator です。 + +**NVIDIA NIM Operator** は、本ワヌクショップで先ほど䜜成した OpenShift クラスタヌのような Kubernetes 環境に LLM をデプロむするために䜿甚したす。 + +このワヌクショップのセクションでは、OpenShift クラスタヌに NVIDIA GPU Operator ず NIM Operator の䞡方をデプロむするために必芁な手順を順を远っお説明したす。 + +## NVIDIA NGC アカりントの䜜成 + +LLM をダりンロヌドしお NVIDIA NIM Operator を䜿甚しおデプロむするには、NVIDIA GPU CLOUD (NGC) アカりントが必芁です。アカりントは [こちら](https://ngc.nvidia.com/signin) から登録できたす。 + +## NVIDIA Developer Program ぞの登録 + +[NVIDIA Developer Program](https://developer.nvidia.com/) に登録するこずで、ワヌクショップの埌半で LLM のデプロむに䜿甚する NVIDIA NIM ぞのアクセスが可胜になりたす。 + +NGC の NVIDIA サブスクリプション䞀芧に `NVIDIA Developer Program` が衚瀺されおいるこずを確認しおください。 + +![NVIDIA Subscriptions](../../images/NVIDIA-Subscriptions.png) + +## NGC API キヌの生成 + +NGC りェブサむトにログむンしたら、画面右䞊のナヌザヌアカりントアむコンをクリックし、**Setup** を遞択したす。 + +次に **Generate API Key** をクリックし、指瀺に埓っおください。キヌが **NGC Catalog** および **Secrets Manager** サヌビスに関連付けられおいるこずを確認しおください。 + +生成されたキヌは、ワヌクショップの埌半で䜿甚するため、安党な堎所に保存しおおきたす。 + +NGC API キヌの生成に関する詳现は、[NVIDIA ドキュメント](https://docs.nvidia.com/ngc/gpu-cloud/ngc-user-guide/index.html#generating-api-key) を参照しおください。 + +## Node Feature Discovery Operator のむンストヌル + +このセクションの手順は、[Installing the NFD Operator using the CLI](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/specialized_hardware_and_driver_enablement/psap-node-feature-discovery-operator#install-operator-cli_psap-node-feature-discovery-operator) に基づいおいたす。 + +次のスクリプトを実行しお、Node Feature Discovery Operator をむンストヌルしたす。 + +``` bash +cd nvidia +./install-nfd-operator.sh +``` + +Operator のデプロむが成功したこずを確認するには、次のコマンドを実行したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +oc get pods +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME READY STATUS RESTARTS AGE +nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 10m +``` + +{{% /tab %}} +{{< /tabs >}} + +## NodeFeatureDiscovery CR の䜜成 + +このセクションの手順は、[Creating a NodeFeatureDiscovery CR by using the CLI](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/specialized_hardware_and_driver_enablement/psap-node-feature-discovery-operator#creating-nfd-cr-cli_psap-node-feature-discovery-operator) に基づいおいたす。 + +次のスクリプトを実行しお、Node Feature Discovery CR を䜜成したす。 + +``` bash +./create-nfd-cr.sh +``` + +## NVIDIA GPU Operator のむンストヌル + +このセクションの手順は、[Installing the NVIDIA GPU Operator on OpenShift](https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/install-gpu-ocp.html#installing-the-nvidia-gpu-operator-on-openshift) に基づいおいたす。 + +次のスクリプトを実行しお、NVIDIA GPU Operator をむンストヌルしたす。 + +``` bash +./install-nvidia-gpu-operator.sh +``` + +むンストヌルプランが䜜成されるたで埅機したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +oc get installplan -n nvidia-gpu-operator +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME CSV APPROVAL APPROVED +install-mmlxq gpu-operator-certified.v25.3.4 Manual false +``` + +{{% /tab %}} +{{< /tabs >}} + +次のコマンドでむンストヌルプランを承認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +INSTALL_PLAN=$(oc get installplan -n nvidia-gpu-operator -oname) +oc patch $INSTALL_PLAN -n nvidia-gpu-operator --type merge --patch '{"spec":{"approved":true }}' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +installplan.operators.coreos.com/install-rc9xq patched +``` + +{{% /tab %}} +{{< /tabs >}} + +## クラスタヌポリシヌの䜜成 + +このセクションの手順は、[Create the cluster policy using the CLI](https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/install-gpu-ocp.html#create-the-cluster-policy-using-the-cli) に基づいおいたす。 + +``` bash +./create-cluster-policy.sh +``` + +## NVIDIA GPU Operator のむンストヌル確認 + +次のコマンドを䜿甚しお、NVIDIA GPU Operator が正垞にむンストヌルされおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +oc get pods,daemonset -n nvidia-gpu-operator +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME READY STATUS RESTARTS AGE +pod/gpu-feature-discovery-sblkn 1/1 Running 0 5m5s +pod/gpu-feature-discovery-zpt94 1/1 Running 0 4m58s +pod/gpu-operator-6579bc6fdc-cp28l 1/1 Running 0 23m +pod/nvidia-container-toolkit-daemonset-qfcl9 1/1 Running 0 5m5s +pod/nvidia-container-toolkit-daemonset-zbwb6 1/1 Running 0 4m59s +pod/nvidia-cuda-validator-f7tl2 0/1 Completed 0 78s +pod/nvidia-cuda-validator-t7n9g 0/1 Completed 0 71s +pod/nvidia-dcgm-exporter-gk66x 1/1 Running 0 4m59s +pod/nvidia-dcgm-exporter-w8kr8 1/1 Running 2 (52s ago) 5m5s +pod/nvidia-dcgm-lrnzr 1/1 Running 0 4m58s +pod/nvidia-dcgm-tvrdm 1/1 Running 0 5m5s +pod/nvidia-device-plugin-daemonset-d62nk 1/1 Running 0 5m5s +pod/nvidia-device-plugin-daemonset-fnv4j 1/1 Running 0 4m59s +pod/nvidia-driver-daemonset-418.94.202509100653-0-5xbvq 2/2 Running 0 5m48s +pod/nvidia-driver-daemonset-418.94.202509100653-0-hmkdl 2/2 Running 0 5m48s +pod/nvidia-node-status-exporter-2kqwr 1/1 Running 0 5m44s +pod/nvidia-node-status-exporter-n8d9s 1/1 Running 0 5m44s +pod/nvidia-operator-validator-r2nm2 1/1 Running 0 5m5s +pod/nvidia-operator-validator-w2fpn 1/1 Running 0 4m59s + +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +daemonset.apps/gpu-feature-discovery 2 2 2 2 2 nvidia.com/gpu.deploy.gpu-feature-discovery=true 5m45s +daemonset.apps/nvidia-container-toolkit-daemonset 2 2 2 2 2 nvidia.com/gpu.deploy.container-toolkit=true 5m48s +daemonset.apps/nvidia-dcgm 2 2 2 2 2 nvidia.com/gpu.deploy.dcgm=true 5m46s +daemonset.apps/nvidia-dcgm-exporter 2 2 2 2 2 nvidia.com/gpu.deploy.dcgm-exporter=true 5m46s +daemonset.apps/nvidia-device-plugin-daemonset 2 2 2 2 2 nvidia.com/gpu.deploy.device-plugin=true 5m47s +daemonset.apps/nvidia-device-plugin-mps-control-daemon 0 0 0 0 0 nvidia.com/gpu.deploy.device-plugin=true,nvidia.com/mps.capable=true 5m47s +daemonset.apps/nvidia-driver-daemonset-418.94.202509100653-0 2 2 2 2 2 feature.node.kubernetes.io/system-os_release.OSTREE_VERSION=418.94.202509100653-0,nvidia.com/gpu.deploy.driver=true 5m48s +daemonset.apps/nvidia-mig-manager 0 0 0 0 0 nvidia.com/gpu.deploy.mig-manager=true 5m45s +daemonset.apps/nvidia-node-status-exporter 2 2 2 2 2 nvidia.com/gpu.deploy.node-status-exporter=true 5m44s +daemonset.apps/nvidia-operator-validator 2 2 2 2 2 nvidia.com/gpu.deploy.operator-validator=true 5m48s +``` + +{{% /tab %}} +{{< /tabs >}} + +## Operator SDK のむンストヌル + +このセクションの手順は、[Install from GitHub release](https://sdk.operatorframework.io/docs/installation/#install-from-github-release) に基づいおいたす。 + +### リリヌスバむナリのダりンロヌド + +プラットフォヌム情報を蚭定したす。 + +``` bash +export ARCH=$(case $(uname -m) in x86_64) echo -n amd64 ;; aarch64) echo -n arm64 ;; *) echo -n $(uname -m) ;; esac) +export OS=$(uname | awk '{print tolower($0)}') +``` + +お䜿いのプラットフォヌム向けのバむナリをダりンロヌドしたす。 + +``` bash +export OPERATOR_SDK_DL_URL=https://github.com/operator-framework/operator-sdk/releases/download/v1.41.1 +curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_${OS}_${ARCH} +``` + +### ダりンロヌドしたバむナリの怜蚌 + +keyserver.ubuntu.com から operator-sdk リリヌスの GPG キヌをむンポヌトしたす。 + +``` bash +gpg --keyserver keyserver.ubuntu.com --recv-keys 052996E2A20B5C7E +``` + +チェックサムファむルずその眲名をダりンロヌドし、眲名を怜蚌したす。 + +``` bash +curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt +curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt.asc +gpg -u "Operator SDK (release) " --verify checksums.txt.asc +``` + +次のような出力が衚瀺されるはずです。 + +``` bash +gpg: assuming signed data in 'checksums.txt' +gpg: Signature made Fri 30 Oct 2020 12:15:15 PM PDT +gpg: using RSA key ADE83605E945FA5A1BD8639C59E5B47624962185 +gpg: Good signature from "Operator SDK (release) " [ultimate] +``` + +チェックサムが䞀臎するこずを確認したす。 + +``` bash +grep operator-sdk_${OS}_${ARCH} checksums.txt | sha256sum -c - +``` + +次のような出力が衚瀺されるはずです。 + +``` bash +operator-sdk_linux_amd64: OK +``` + +### リリヌスバむナリを PATH にむンストヌル + +``` bash +chmod +x operator-sdk_${OS}_${ARCH} && sudo mv operator-sdk_${OS}_${ARCH} /usr/local/bin/operator-sdk +``` + +## NGC CLI のむンストヌル + +このセクションの手順は、[NGC CLI Install](https://org.ngc.nvidia.com/setup/installers/cli) に基づいおいたす。 + +Download CLI をクリックしおバむナリを含む zip ファむルをダりンロヌドし、暩限のあるディレクトリに転送しおから、解凍しおバむナリを実行したす。実行暩限のあるディレクトリに移動しお次のコマンドを実行するこずで、コマンドラむンからダりンロヌド、解凍、むンストヌルを行うこずもできたす。 + +``` bash +wget --content-disposition https://api.ngc.nvidia.com/v2/resources/nvidia/ngc-apps/ngc_cli/versions/4.3.0/files/ngccli_linux.zip -O ngccli_linux.zip && unzip ngccli_linux.zip +``` + +ダりンロヌド時にファむルが砎損しおいないこずを確認するため、バむナリの md5 ハッシュをチェックしたす。 + +``` bash +find ngc-cli/ -type f -exec md5sum {} + | LC_ALL=C sort | md5sum -c ngc-cli.md5 +``` + +ダりンロヌド時にファむルが砎損しおいないこずを確認するため、バむナリの SHA256 ハッシュをチェックしたす。次のコマンドを実行しおください。 + +``` bash +sha256sum ngccli_linux.zip +``` + +リ゜ヌスのリリヌスノヌトにも蚘茉されおいる、次の倀ず比范したす。 + +``` bash +5f01eff85a66c895002f3c87db2933c462f3b86e461e60d515370f647b4ffc21 +``` + +倀を確認したら、NGC CLI バむナリを実行可胜にし、珟圚のディレクトリを PATH に远加したす。 + +``` bash +chmod u+x ngc-cli/ngc +echo "export PATH=\"\$PATH:$(pwd)/ngc-cli\"" >> ~/.bash_profile && source ~/.bash_profile +``` + +コマンドを実行できるようにするため、NGC CLI を蚭定する必芁がありたす。 + +次のコマンドを入力し、プロンプトが衚瀺されたら API キヌを入力したす。 + +``` bash +ngc config set +``` + +NGC API キヌを環境倉数ずしお定矩したす。 + +``` bash +export NGC_API_KEY= +``` + +## NVIDIA NIM Operator のむンストヌル + +このセクションの手順は、[Installing NIM Operator on Red Hat OpenShift Using operator-sdk (for Development-Only)](https://docs.nvidia.com/nim-operator/latest/install.html#installing-nim-operator-on-red-hat-openshift-using-operator-sdk-for-development-only) に基づいおいたす。 + +次のスクリプトを実行しお、NIM Operator をむンストヌルしたす。 + +``` bash +./install-nim-operator.sh +``` + +コントロヌラヌ Pod が実行䞭であるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +oc get pods -n nvidia-nim-operator +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +NAME READY STATUS RESTARTS AGE +ec60a4439c710b89fc2582f5384382b4241f9aee62bb3182b8d128e69dx54dc 0/1 Completed 0 61s +ghcr-io-nvidia-k8s-nim-operator-bundle-latest-main 1/1 Running 0 71s +k8s-nim-operator-86d478b55c-w5cf5 1/1 Running 0 50s +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md new file mode 100644 index 0000000000..4bc84e5f8f --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md @@ -0,0 +1,172 @@ +--- +title: ナヌザヌのセットアップ +linkTitle: 6. ナヌザヌのセットアップ +weight: 6 +time: 5 minutes +--- + +このセクションでは、ワヌクショップ参加者ごずにナヌザヌを䜜成し、それぞれに namespace ずリ゜ヌス +クォヌタを割り圓おたす。 + +## ナヌザヌ namespace ずリ゜ヌスクォヌタの䜜成 + +``` bash +cd user-setup +./create-namespaces.sh +``` + +## ナヌザヌの䜜成 + +参加者の認蚌情報を含む HTPasswd ファむルを䜜成し、ROSA が管理する HTPasswd IdP を +カスタムのものに眮き換えたす。 + +``` bash +./create-users.sh +``` + +## cluster-admin ナヌザヌの再䜜成ず再ログむン + +cluster-admin ナヌザヌを再䜜成し、再床ログむンしたす。 + +``` bash +rosa create admin -c rosa-test +oc login --username cluster-admin --password +``` + +## ナヌザヌぞのロヌル远加 + +各ナヌザヌに、自身の namespace のみぞのアクセス暩を付䞎したす。 + +``` bash +./add-role-to-users.sh +``` + +泚意: 以䞋のような゚ラヌが衚瀺される堎合がありたすが、無芖しお問題ありたせん。 + +```` +Warning: User 'participant1' not found +clusterrole.rbac.authorization.k8s.io/admin added: "participant1" +```` + +## ログむンのテスト + +### OpenShift CLI のむンストヌル + +ロヌカルマシンからログむンをテストするために、OpenShift CLI をむンストヌルする必芁がありたす。 + +MacOS の堎合は、Homebrew パッケヌゞマネヌゞャヌを䜿甚しお OpenShift CLI をむンストヌルできたす。 + +``` bash +brew install openshift-cli +``` + +その他のむンストヌル方法に぀いおは、[OpenShift ドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/cli_tools/openshift-cli-oc) を参照しおください。 + +### ワヌクショップナヌザヌずしおのログむン + +ロヌカルマシンからワヌクショップナヌザヌの 1 人ずしおログむンを詊みたす。 + +``` bash +oc login https://api.:443 -u participant1 -p 'TempPass123!' +``` + +以䞋のようなメッセヌゞが衚瀺されるはずです。 + +```` +Login successful. + +You have one project on this server: "workshop-participant-1" +```` + +### LLM ぞのアクセス確認 + +ワヌクショップナヌザヌアカりントから LLM にアクセスできるこずを確認したす。 + +curl コマンドを䜿甚できる pod を起動したす。 + +``` bash +oc run curl --rm -it --image=curlimages/curl:latest \ + --overrides='{ + "spec": { + "containers": [{ + "name": "curl", + "image": "curlimages/curl:latest", + "stdin": true, + "tty": true, + "command": ["sh"], + "resources": { + "limits": { + "cpu": "50m", + "memory": "100Mi" + }, + "requests": { + "cpu": "50m", + "memory": "100Mi" + } + } + }] + } + }' +``` + +次に、以䞋のコマンドを実行しお LLM にプロンプトを送信したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +curl -X "POST" \ + 'http://meta-llama-3-2-1b-instruct.nim-service:8000/v1/chat/completions' \ + -H 'Accept: application/json' \ + -H 'Content-Type: application/json' \ + -d '{ + "model": "meta/llama-3.2-1b-instruct", + "messages": [ + { + "content":"What is the capital of Canada?", + "role": "user" + }], + "top_p": 1, + "n": 1, + "max_tokens": 1024, + "stream": false, + "frequency_penalty": 0.0, + "stop": ["STOP"] + }' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +{ + "id": "chatcmpl-2ccfcd75a0214518aab0ef0375f8ca21", + "object": "chat.completion", + "created": 1758919002, + "model": "meta/llama-3.2-1b-instruct", + "choices": [ + { + "index": 0, + "message": { + "role": "assistant", + "reasoning_content": null, + "content": "The capital of Canada is Ottawa.", + "tool_calls": [] + }, + "logprobs": null, + "finish_reason": "stop", + "stop_reason": null + } + ], + "usage": { + "prompt_tokens": 42, + "total_tokens": 50, + "completion_tokens": 8, + "prompt_tokens_details": null + }, + "prompt_logprobs": null +} +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md new file mode 100644 index 0000000000..f50c81978c --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md @@ -0,0 +1,107 @@ +--- +title: OpenTelemetry Collector のむンストヌル +linkTitle: 7. OpenTelemetry Collector のむンストヌル +weight: 7 +time: 5 minutes +--- + +このセクションでは、clusterReceiver のみを有効化した OpenTelemetry collector をむンストヌルしたす +ワヌクショップ参加者は各自の namespace に独自の゚ヌゞェントをむンストヌルするため。 +その埌、この collector のむンストヌルによっお䜜成された ClusterRole を、 +各ワヌクショップ参加者の namespace にバむンドしたす。 + +## OpenTelemetry Collector のむンストヌル + +たず、collector 甚の新しいプロゞェクトを䜜成し、そのプロゞェクトに切り替えたす: + +```bash +oc new-project admin-otel +``` + +Splunk OpenTelemetry Collector for Kubernetes の Helm chart リポゞトリを远加したす: + +```bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart +```` + +リポゞトリが最新であるこずを確認したす: + +```bash +helm repo update +```` + +OpenTelemetry collector のむンストヌルに䜿甚する `./admin-otel-collector/admin-otel-collector-values.yaml` +ファむルの内容を確認しおください。 + +collector がデヌタを送信する Splunk 環境を蚭定するため、環境倉数を蚭定したす: + +``` bash +export CLUSTER_NAME=ai-pod-workshop-admin +export ENVIRONMENT_NAME=ai-pod-workshop-admin +export SPLUNK_ACCESS_TOKEN= +export SPLUNK_REALM= +export SPLUNK_HEC_URL=:443/services/collector/event> +export SPLUNK_HEC_TOKEN= +export SPLUNK_INDEX=splunk4rookies-workshop +``` + +次に、以䞋のコマンドで collector をむンストヌルしたす: + +```bash +helm install splunk-otel-collector \ + --set="clusterName=$CLUSTER_NAME" \ + --set="environment=$ENVIRONMENT_NAME" \ + --set="splunkObservability.accessToken=$SPLUNK_ACCESS_TOKEN" \ + --set="splunkObservability.realm=$SPLUNK_REALM" \ + --set="splunkPlatform.endpoint=$SPLUNK_HEC_URL" \ + --set="splunkPlatform.token=$SPLUNK_HEC_TOKEN" \ + --set="splunkPlatform.index=$SPLUNK_INDEX" \ + -f ./admin-otel-collector/admin-otel-collector-values.yaml \ + -n admin-otel \ + splunk-otel-collector-chart/splunk-otel-collector +``` + +以䞋のコマンドを実行しお、すべおの collector の pod が動䜜しおいるこずを確認したす: + +```` +oc get pods -n admin-otel + +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-k8s-cluster-receiver-7b7f5cdc5b-rhxsj 1/1 Running 0 6m40s +```` + +## 各ワヌクショップ参加者甚の Service Account の䜜成ず Cluster Role ぞのバむンド + +``` bash +for i in {1..30}; do + ns="workshop-participant-$i" + + oc get ns "$ns" >/dev/null 2>&1 || continue + oc -n "$ns" create sa splunk-otel-collector 2>/dev/null || true + + oc apply -f - </dev/null 2>&1 || continue + oc -n "$ns" adm policy add-scc-to-user splunk-otel-collector -z splunk-otel-collector +done +``` diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md new file mode 100644 index 0000000000..9ee7b1d763 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md @@ -0,0 +1,79 @@ +--- +title: Deploy the Vector Database +linkTitle: 8. Deploy the Vector Database +weight: 8 +time: 10 minutes +--- + +このステップでは、OpenShiftクラスタヌにベクトルデヌタベヌスをデプロむし、ワヌクショップ参加者が䜿甚するテストデヌタを投入したす。 + +## Deploy a Vector Database + +このワヌクショップでは、オヌプン゜ヌスのベクトルデヌタベヌスである [Weaviate](https://weaviate.io/) をデプロむしたす。 + +たず、Weaviate helm chartが含たれおいるWeaviate helmリポゞトリを远加したす。 + +``` bash +helm repo add weaviate https://weaviate.github.io/weaviate-helm +helm repo update +``` + +`weaviate/weaviate-values.yaml` ファむルには、Weaviateベクトルデヌタベヌスをデプロむするために䜿甚する蚭定が含たれおいたす。 + +埌ほどPrometheus receiverでスクレむプできるメトリクスをWeaviateが公開するように、以䞋の環境倉数を `TRUE` に蚭定しおいたす。 + +```` + PROMETHEUS_MONITORING_ENABLED: true + PROMETHEUS_MONITORING_GROUP: true +```` + +利甚可胜なその他のカスタマむズオプションに぀いおは、[Weaviate documentation](https://docs.weaviate.io/deploy/installation-guides/k8s-installation) を参照しおください。 + +新しいnamespaceを䜜成したす。 + +``` bash +oc create namespace weaviate +``` + +Weaviateが特暩コンテナを実行できるように、以䞋のコマンドを実行したす。 + +> 泚: このアプロヌチは本番環境では掚奚されたせん + +``` bash +oc adm policy add-scc-to-user privileged -z default -n weaviate +``` + +続いおWeaviateをデプロむしたす。 + +``` bash +helm upgrade --install \ + "weaviate" \ + weaviate/weaviate \ + --namespace "weaviate" \ + --values ./weaviate/weaviate-values.yaml +``` + +## Populate the Vector Database + +Weaviateが起動したので、カスタムアプリケヌションを䜿っおワヌクショップで利甚するデヌタを投入しおいきたす。 + +このために䜿甚するアプリケヌションは、[LangChain Playbook for NeMo Retriever Text Embedding NIM](https://docs.nvidia.com/nim/nemo-retriever/text-embedding/latest/playbook.html#generate-embeddings-with-text-embedding-nim) をベヌスにしおいたす。 + +`./load-embeddings/k8s-job.yaml` の蚭定に埓い、[datasheet for the NVIDIA H200 Tensor Core GPU](https://nvdam.widen.net/content/udc6mzrk7a/original/hpc-datasheet-sc23-h200-datasheet-3002446.pdf) をベクトルデヌタベヌスにロヌドしたす。 + +このドキュメントには、私たちが利甚する倧芏暡蚀語モデルが孊習しおいないNVIDIA H200 GPUに関する情報が含たれおいたす。ワヌクショップの次のパヌトでは、このドキュメントをベクトルデヌタベヌスにロヌドしたうえで、その内容をコンテキストずしお利甚しおLLMが質問に回答するアプリケヌションを構築したす。 + +OpenShiftクラスタヌにKubernetes Jobをデプロむしお、゚ンベディングをロヌドしたす。このプロセスを䞀床だけ実行するこずを保蚌するため、PodではなくKubernetes Jobを䜿甚したす。 + +``` bash +oc create namespace llm-app +oc apply -f ./load-embeddings/k8s-job.yaml +``` + +> 泚: ゚ンベディングをWeaviateにロヌドするPythonアプリケヌションのDockerむメヌゞをビルドする際には、以䞋のコマンドを実行したした。 +> +> ``` bash +> cd workshop/cisco-ai-pods/load-embeddings +> docker build --platform linux/amd64 -t derekmitchell399/load-embeddings:1.0 . +> docker push derekmitchell399/load-embeddings:1.0 +> ``` diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md new file mode 100644 index 0000000000..cb73211371 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md @@ -0,0 +1,50 @@ +--- +title: Portworx メトリクス゚ンドポむントのデプロむ +linkTitle: 9. Portworx メトリクス゚ンドポむント +weight: 9 +time: 10 minutes +--- + +このステップでは、Portworx のメトリクス゚ンドポむントを暡倣する Python サヌビスをデプロむしたす。 +これは、ワヌクショップで Pure Storage の監芖を蚭定するために䜿甚したす。 + +## Portworx メトリクス゚ンドポむントのデプロむ + +以䞋のコマンドを実行しお、Portworx メトリクス゚ンドポむントサヌビスをデプロむしたす。 + +``` bash +oc new-project portworx +oc apply -f ./portworx/k8s.yaml -n portworx +``` + +## Portworx メトリクス゚ンドポむントのテスト + +Portworx メトリクス゚ンドポむントが想定どおりに動䜜しおいるこずを確認したしょう。 + +curl コマンドを利甚できる Pod を起動したす。 + +``` bash +oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh +``` + +続いお、以䞋のコマンドを実行しお゚ンドポむントにリク゚ストを送信したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +curl http://portworx-metrics-sim.portworx:17001/metrics +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +# HELP px_cluster_cpu_percent Percentage of CPU Used +# TYPE px_cluster_cpu_percent gauge +px_cluster_cpu_percent{cluster="ocp-pxclus-32430549-ad99-4839-bf9b-d6beb8ddc2d6",clusterUUID="e870909b-6150-4d72-87cb-a012630e42ae",node="worker2.flashstack.local",nodeID="f63312a2-0884-4878-be4e-51935613aa80"} 1.91 +... +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md new file mode 100644 index 0000000000..cf8e36b511 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md @@ -0,0 +1,17 @@ +--- +title: Workshop Setup +linkTitle: 1. Workshop Setup +weight: 1 +--- + +このセクションには、ワヌクショップ䞻催者がワヌクショップをセットアップするために実行すべき手順が含たれたす。 + +* AWS アカりントのセットアップ +* OpenShift の前提条件 +* AWS ROSA を䜿甚しお、GPU ベヌスのワヌカヌノヌドを持぀ **RedHat OpenShift** クラスタヌをデプロむしたす。 +* **NVIDIA NIM Operator** ず **NVIDIA GPU Operator** をデプロむしたす。 +* NVIDIA NIM を䜿甚しおクラスタヌに **Large Language Model (LLM)** をデプロむしたす。 +* 適切な暩限を持぀ OpenShift ログむンず名前空間を、各ワヌクショップナヌザヌ向けに䜜成したす。 +* **Splunk OpenTelemetry collector** の Cluster Receiver コンポヌネントをむンストヌルしたす。 +* クラスタヌに **Weviate vector database** をデプロむしたす。 +* **Portworx Prometheus exporter** を暡倣するサヌビスをデプロむしたす。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md new file mode 100644 index 0000000000..3f72cbb6b6 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md @@ -0,0 +1,57 @@ +--- +title: ワヌクショップ環境の抂芁 +linkTitle: 1. ワヌクショップ環境の抂芁 +weight: 1 +time: 5 minutes +--- + +**Cisco's AI-ready PODs** は、最先端のハヌドりェアず゜フトりェアを組み合わせ、 +堅牢でスケヌラブル、か぀効率的なAIむンフラストラクチャを提䟛したす。 +**Splunk Observability Cloud** は、むンフラストラクチャからアプリケヌションコンポヌネントに至るたで、 +このスタック党䜓を包括的に可芖化したす。 + +このハンズオンワヌクショップでは、OpenTelemetryずPrometheusを䜿甚しおAIむンフラストラクチャを監芖する方法を、 +**実際のCisco AI PODぞのアクセスを必芁ずせずに** 孊習したす。 +珟実的な環境で監芖技術をデプロむし蚭定する実践的な経隓を埗られたす。 + +## ラボ環境 + +このワヌクショップでは、AWS䞊で動䜜する共有 **OpenShift Cluster** を䜿甚したす。 +このクラスタヌはNVIDIA GPUおよびNVIDIA AI Enterprise゜フトりェアを備えおいたす。 + +### 事前デプロむ枈みのむンフラストラクチャ + +ワヌクショップのむンストラクタヌは、以䞋の共有コンポヌネントをワヌクショップ環境にデプロむ枈みです: + +* **NVIDIA NIM models**: + * `meta/llama-3.2-1b-instruct` - ナヌザヌプロンプトを凊理したす + * `nvidia/llama-3.2-nv-embedqa-1b-v2` - ゚ンベディングを生成したす +* **Weaviate** - セマンティック怜玢ず取埗のためのベクトルデヌタベヌスです +* **Prometheus exporter** - 本番AI PODに兞型的なPure Storageメトリクスをシミュレヌトしたす + +### あなたのワヌクスペヌス + +各参加者には共有クラスタヌ内に専甚の名前空間が割り圓おられ、 +独立した䜜業のための分離された環境が確保されたす。 + +## ワヌクショップのアクティビティ + +ワヌクショップの䞭で、各参加者は以䞋のタスクを実行したす: + +1. 自分の名前空間に **OpenTelemetry collector** をデプロむしお蚭定したす +2. クラスタヌむンフラストラクチャずオブザヌバビリティデヌタ収集を統合したす +3. NVIDIA NIM modelsを掻甚する **Python application** をデプロむしたす +4. Splunk Observability Cloudを䜿甚しおアプリケヌションのパフォヌマンスずむンフラストラクチャメトリクスを監芖したす + +## Prometheusずは + +**Prometheus** は通垞、ストレヌゞずアラヌト甚途に䜿われるフルスタックの監芖システムを指したすが、 +このワヌクショップではPrometheus゚コシステムのデヌタ暙準に焊点を圓おたす。 + +ここでは **Prometheus Exporters** を掻甚したす。これは、コンポヌネントの内郚状態を暙準化された +メトリクス゚ンドポむント (䟋: ) に倉換する小さなナヌティリティです。 + +このデヌタの収集にPrometheusサヌバヌ党䜓を䜿甚する代わりに、 +**OpenTelemetry Collector** を䜿甚したす。コレクタヌの **Prometheus receiver** を䜿うこずで、 +これらの゚ンドポむントを **scrape** するこずができ、広くサポヌトされた業界暙準フォヌマットを甚いお +豊富なテレメトリデヌタを収集できたす。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md new file mode 100644 index 0000000000..f5363044bc --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md @@ -0,0 +1,79 @@ +--- +title: LLM アプリケヌションのデプロむ +linkTitle: 10. LLM アプリケヌションのデプロむ +weight: 10 +time: 10 minutes +--- + +## LLM アプリケヌションのデプロむ + +以䞋のコマンドを䜿甚しお、このアプリケヌションを OpenShift クラスタヌにデプロむしたす。 + +``` bash +cd ~/workshop/cisco-ai-pods +oc apply -f ./llm-app/k8s-manifest.yaml +``` + +> 泚意: この Python アプリケヌションの Docker むメヌゞをビルドするために、以䞋のコマンドを実行したした。 +> +> ``` bash +> cd workshop/cisco-ai-pods/llm-app +> docker build --platform linux/amd64 -t ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0 . +> docker push ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0 +> ``` + +## LLM アプリケヌションのテスト + +アプリケヌションが期埅どおりに動䜜しおいるこずを確認したしょう。 + +curl コマンドを利甚できる Pod を起動したす。 + +``` bash +oc run curl --rm -it --image=curlimages/curl:latest \ + --overrides='{ + "spec": { + "containers": [{ + "name": "curl", + "image": "curlimages/curl:latest", + "stdin": true, + "tty": true, + "command": ["sh"], + "resources": { + "limits": { + "cpu": "50m", + "memory": "100Mi" + }, + "requests": { + "cpu": "50m", + "memory": "100Mi" + } + } + }] + } + }' +``` + +続いお、以䞋のコマンドを実行しお LLM に質問を送信したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +curl -X "POST" \ + 'http://llm-app:8080/askquestion' \ + -H 'Accept: application/json' \ + -H 'Content-Type: application/json' \ + -d '{ + "question": "How much memory does the NVIDIA H200 have?" + }' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +The NVIDIA H200 has 141GB of HBM3e memory, which is twice the capacity of the NVIDIA H100 Tensor Core GPU with 1.4X more memory bandwidth. +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md new file mode 100644 index 0000000000..e8c8ed7427 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md @@ -0,0 +1,39 @@ +--- +title: メトリクス、トレヌス、ログの確認 +linkTitle: 11. メトリクス、トレヌス、ログの確認 +weight: 11 +time: 10 minutes +--- + +## Splunk Observability Cloud でトレヌスデヌタを衚瀺する + +Splunk Observability Cloud で `APM` に移動し、`Service Map` を遞択したす。 +環境名䟋`ai-pod-workshop-participant-1`が遞択されおいるこずを確認したす。 +以䞋のようなサヌビスマップが衚瀺されるはずです。 + +![Service Map](../../images/ServiceMap.png) + +右偎のメニュヌにある `Traces` をクリックしたす。次に、実行時間が比范的長いトレヌスの 1 ぀を遞択したす。以䞋の䟋のように衚瀺されるはずです。 + +![Trace](../../images/Trace.png) + +このトレヌスは、ナヌザヌの質問䟋「How much memory does the NVIDIA H200 have?」に回答を返すためにアプリケヌションが実行したすべおのむンタラクションを瀺しおいたす。 + +䟋えば、Weaviate ベクトルデヌタベヌス内で圓該質問に関連するドキュメントを探すために、アプリケヌションが類䌌怜玢を実行した箇所を確認できたす。 + +たた、ベクトルデヌタベヌスから取埗したコンテキストを含めお、アプリケヌションが LLM に送信するプロンプトをどのように䜜成したかも確認できたす。 + +![Prompt Template](../../images/PromptTemplate.png) + +> 泚トレヌスのりォヌタヌフォヌルビュヌに `chat` および `invoke_workflow` の AI むンタラクションが衚瀺されない堎合、たたは右偎に `AI details` タブが衚瀺されない堎合は、有効化が必芁な superpowers に぀いお講垫に確認しおください。 + +最埌に、LLM からのレスポンス、所芁時間、および䜿甚された入出力トヌクン数を確認できたす。 + +![LLM Response](../../images/LLMResponse.png) + +## メトリクスが Splunk に送信されおいるこずを確認する + +Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含たれおいる `Cisco AI PODs Dashboard` を怜玢したす。 +`NIM FOR LLMS` タブに移動し、ダッシュボヌドが自分の OpenShift クラスタヌ名でフィルタリングされおいるこずを確認したす。以䞋の䟋のようにチャヌトにデヌタが衚瀺されるはずです。 + +![NIM LLMS Dashboard](../../images/NIMLLM.png) diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md new file mode 100644 index 0000000000..edf23c1682 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md @@ -0,0 +1,22 @@ +--- +title: Wrap-Up +linkTitle: 12. たずめ +weight: 12 +time: 5 minutes +--- + +## たずめ + +このワヌクショップでは、Splunk Observability Cloud で Cisco AI POD を監芖するために䜿甚される +いく぀かの技術のデプロむず操䜜をハンズオンで䜓隓しおいただきたした。 +具䜓的には、以䞋の機䌚を提䟛したした。 + +* GPU ベヌスのワヌカヌノヌドを持぀ RedHat OpenShift クラスタヌでの䜜業 +* NVIDIA NIM Operator および NVIDIA GPU Operator の操䜜 +* NVIDIA NIM を䜿甚しおクラスタヌにデプロむされた倧芏暡蚀語モデルLLMの操䜜 +* Red Hat OpenShift クラスタヌぞの OpenTelemetry Collector のデプロむ +* むンフラストラクチャメトリクスを取り蟌むための Prometheus レシヌバヌをコレクタヌに远加 +* クラスタヌ内の Weaviate ベクトルデヌタベヌスの監芖 +* Prometheus を䜿甚した Pure Storage メトリクスの監芖蚭定 +* 倧芏暡蚀語モデルLLMず連携する Python サヌビスを OpenTelemetry で蚈装 +* LLM ず連携するアプリケヌションのトレヌスで OpenTelemetry がキャプチャする詳现の理解 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md new file mode 100644 index 0000000000..ea1a59d6b0 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md @@ -0,0 +1,84 @@ +--- +title: OpenShift クラスタヌぞの接続 +linkTitle: 2. OpenShift クラスタヌぞの接続 +weight: 2 +time: 5 minutes +--- + +## EC2 むンスタンスぞの接続 + +参加者の皆さた向けに、AWS/EC2 䞊に Ubuntu Linux むンスタンスを甚意しおいたす。 + +むンストラクタヌから提䟛された IP アドレスずパスワヌドを䜿っお、以䞋のいずれかの方法で EC2 むンスタンスに接続しおください。 + +* Mac OS / Linux + * ssh splunk@IP address +* Windows 10 以降 + * OpenSSH クラむアントを䜿甚しおください +* それ以前のバヌゞョンの Windows + * Putty を䜿甚しおください + +## ワヌクショップ参加者番号の蚭定 + +むンストラクタヌから各参加者に 1 から 30 たでの番号が割り圓おられたす。 +この番号は、ワヌクショップ党䜓を通じお䜿甚するため、環境倉数に保存し、忘れないようにしおください。 + +``` bash +export PARTICIPANT_NUMBER= +``` + +## OpenShift CLI のむンストヌル + +OpenShift クラスタヌにアクセスするために、OpenShift CLI をむンストヌルする必芁がありたす。 + +以䞋のコマンドを䜿甚しお、OpenShift CLI のバむナリを EC2 むンスタンスに盎接ダりンロヌドできたす。 + +```` +curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz +```` + +ファむルを展開したす。 + +```` +tar -xvzf openshift-client-linux.tar.gz +```` + +展開されたファむル`oc` ず `kubectl`を、PATH に含たれる堎所に移動したす。䟋えば次のように実行したす。 + +``` bash +sudo mv oc /usr/local/bin/oc +sudo mv kubectl /usr/local/bin/kubectl +``` + +## OpenShift クラスタヌぞの接続 + +splunk ナヌザヌが Kube 蚭定ファむルを倉曎できるようにしたす。 + +``` bash +chmod 600 /home/splunk/.kube/config +``` + +ワヌクショップの䞻催者から提䟛されたクラスタヌ API URL ずパスワヌドを䜿甚しお、OpenShift クラスタヌにログむンしたす。 + +``` bash +oc login https://api.:443 -u participant$PARTICIPANT_NUMBER -p '' +``` + +OpenShift クラスタヌに接続できおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +oc whoami --show-server +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +https://api.***.openshiftapps.com:443 +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md new file mode 100644 index 0000000000..e53a366466 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md @@ -0,0 +1,146 @@ +--- +title: OpenTelemetry Collectorのデプロむ +linkTitle: 3. OpenTelemetry collectorのデプロむ +weight: 3 +time: 10 minutes +--- + +このセクションでは、OpenShiftのネヌムスペヌスにOpenTelemetry Collectorをデプロむしたす。 +OpenTelemetry Collectorは、クラスタヌ䞊で皌働するむンフラストラクチャやアプリケヌションから +メトリクス、ログ、トレヌスを収集し、そのデヌタをSplunk Observability Cloudに送信したす。 + +## OpenTelemetry Collectorのデプロむ + +### Helmのむンストヌル確認 + +以䞋のコマンドを実行しお、Helmがむンストヌルされおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +helm version +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37d847793e", GitTreeState:"clean", GoVersion:"go1.24.11"} +``` + +{{% /tab %}} +{{< /tabs >}} + +むンストヌルされおいない堎合は、以䞋のコマンドを実行しおください。 + +``` bash +sudo apt-get install curl gpg apt-transport-https --yes +curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null +echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list +sudo apt-get update +sudo apt-get install helm +``` + +### Splunk OpenTelemetry Collector Helm Chartの远加 + +Splunk OpenTelemetry Collector for KubernetesのHelm chartリポゞトリを远加したす。 + +```bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart +```` + +リポゞトリが最新であるこずを確認したす。 + +```bash +helm repo update +```` + +### 環境倉数の蚭定 + +Collectorがデヌタを送信するSplunk環境を構成するために、環境倉数を蚭定したす。 + +``` bash +export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER +export CLUSTER_NAME=ai-pod-$USER_NAME +export ENVIRONMENT_NAME=ai-pod-$USER_NAME +export SPLUNK_INDEX=splunk4rookies-workshop +``` + +環境名が蚭定されおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +echo $ENVIRONMENT_NAME +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` bash +ai-pod-workshop-participant-1 +``` + +{{% /tab %}} +{{< /tabs >}} + +### Collectorのデプロむ + +ワヌクショップディレクトリぞ移動したす。 + +``` bash +cd ~/workshop/cisco-ai-pods +``` + +次に、以䞋のコマンドを䜿甚しおネヌムスペヌスにCollectorをむンストヌルしたす。 + +```bash +{ [ -z "$CLUSTER_NAME" ] || \ + [ -z "$ENVIRONMENT_NAME" ] || \ + [ -z "$USER_NAME" ]; } && \ + echo "Error: Missing variables" || \ + helm upgrade --install splunk-otel-collector \ + --set="clusterName=$CLUSTER_NAME" \ + --set="environment=$ENVIRONMENT_NAME" \ + --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ + --set="splunkObservability.realm=$REALM" \ + --set="splunkPlatform.endpoint=$HEC_URL" \ + --set="splunkPlatform.token=$HEC_TOKEN" \ + --set="splunkPlatform.index=$SPLUNK_INDEX" \ + -f ./otel-collector/otel-collector-values.yaml \ + -n $USER_NAME \ + splunk-otel-collector-chart/splunk-otel-collector +``` + +> 泚: `Missing variables`ずいう゚ラヌが衚瀺された堎合は、環境倉数を再床定矩する必芁がありたす。 +> 以䞋のコマンドを実行する前に、参加者番号を远加しおください。 +> +> ``` bash +> export PARTICIPANT_NUMBER= +> export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER +> export CLUSTER_NAME=ai-pod-$USER_NAME +> export ENVIRONMENT_NAME=ai-pod-$USER_NAME +> export SPLUNK_INDEX=splunk4rookies-workshop +> ``` + +以䞋のコマンドを実行しお、Collectorのpodが皌働しおいるこずを確認したす。 + +```` +watch -n 1 oc get pods + +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-58rwm 1/1 Running 0 6m40s +splunk-otel-collector-agent-8dndr 1/1 Running 0 6m40s +```` + +> 泚: OpenShift環境では、Collectorが起動しお`Running`状態に遷移するたでに玄3分かかりたす。 + +### Splunk Observability CloudでのCollectorデヌタの確認 + +**Splunk Observability Cloud**でクラスタヌが衚瀺されるこずを確認したす。 +**Infrastructure Monitoring** -> **Kubernetes** -> **Kubernetes Clusters**に移動し、 +`k8s.cluster.name`に察しお自分のクラスタヌ名䟋: `ai-pod-workshop-participant-1`でフィルタヌを远加しおください。 + +![Kubernetes Pods](../../images/KubernetesPods.png) diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md new file mode 100644 index 0000000000..137bbbf89e --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md @@ -0,0 +1,225 @@ +--- +title: NVIDIA コンポヌネントの監芖 +linkTitle: 4. NVIDIA コンポヌネントの監芖 +weight: 4 +time: 10 minutes +--- + +このセクションでは、OpenTelemetry collector で Prometheus **receiver** を䜿っお、 +OpenShift クラスタ䞊で皌働しおいる NVIDIA コンポヌネントを監芖したす。 +たず、collector の蚭定ファむルが栌玍されおいるディレクトリぞ移動したす。 + +``` bash +cd otel-collector +``` + +## NVIDIA DCGM Exporter のメトリクスを取埗する + +[NVIDIA DCGM exporter](https://github.com/NVIDIA/dcgm-exporter) は OpenShift クラスタで皌働しおいたす。 +これは Splunk ぞ送信できる GPU メトリクスを公開しおいたす。 + +これを行うために、collector のデプロむ時に䜿甚した `otel-collector-values.yaml` ファむルを線集しお、 +collector の蚭定をカスタマむズしたしょう。 + +`kubeletstats` **receiver** の盎䞋に、以䞋の内容を远加したす。 + +``` yaml + receiver_creator/nvidia: + # Name of the extensions to watch for endpoints to start and stop. + watch_observers: [ k8s_observer ] + receivers: + prometheus/dcgm: + config: + config: + scrape_configs: + - job_name: gpu-metrics + scrape_interval: 60s + static_configs: + - targets: + - '`endpoint`:9400' + rule: type == "pod" && labels["app"] == "nvidia-dcgm-exporter" +``` + +これにより、collector は `app=nvidia-dcgm-exporter` ずいうラベルを持぀ Pod を探すようになりたす。 +このラベルを持぀ Pod を芋぀けるず、その Pod のポヌト 9400 に接続し、 +デフォルトのメトリクス゚ンドポむント (`/v1/metrics`) をスクレむピングしたす。 + +> なぜ **Prometheus** receiver だけでなく **receiver_creator** receiver を䜿うのでしょうか +> +> * **Prometheus** receiver は、事前に定矩された゚ンドポむントからメトリクスをスクレむピングする静的な蚭定を䜿甚したす。 +> * **receiver_creator** receiver は、ランタむム情報に基づいお受信機Prometheus receiver を含むを動的に䜜成できるため、スケヌラブルで柔軟なスクレむピング構成を実珟できたす。 +> * **receiver_creator** を䜿甚するこずで、耇数の Prometheus スクレむピング察象の管理を自動化し、動的な環境における蚭定をシンプルにできたす。 + +この新しい **receiver** が䜿われるようにするため、`otel-collector-values.yaml` ファむルに新しい **pipeline** も远加する必芁がありたす。 + +ファむルの末尟に以䞋のコヌドを远加したす。 + +``` yaml + service: + pipelines: + metrics/nvidia-metrics: + exporters: + - signalfx + processors: + - memory_limiter + - batch + - resourcedetection + - resource + receivers: + - receiver_creator/nvidia +``` + +NVIDIA に関連する Prometheus **receiver** を、次のセクションでもう 1 ぀远加したす。 + +## NVIDIA NIM のメトリクスを取埗する + +`meta-llama-3-2-1b-instruct` 倧芏暡蚀語モデルは、NVIDIA NIM を䜿甚しお OpenShift クラスタにデプロむされおいたす。 +このモデルには、collector でスクレむピング可胜な Prometheus ゚ンドポむントが含たれおいたす。 +先ほど远加した `prometheus/dcgm` **receiver** の盎䞋に、以䞋の内容を `otel-collector-values.yaml` ファむルぞ远加したす。 + +``` yaml + prometheus/nim-llm: + config: + config: + scrape_configs: + - job_name: nim-for-llm-metrics + scrape_interval: 60s + metrics_path: /v1/metrics + static_configs: + - targets: + - '`endpoint`:8000' + rule: type == "pod" && labels["app"] == "meta-llama-3-2-1b-instruct" +``` + +これにより、collector は `app=meta-llama-3-2-1b-instruct` ずいうラベルを持぀ Pod を探すようになりたす。 +このラベルを持぀ Pod を芋぀けるず、その Pod のポヌト 8000 に接続し、 +`/v1/metrics` メトリクス゚ンドポむントをスクレむピングしたす。 + +この **receiver** は `receiver_creator/nvidia` receiver の䞀郚ずしお既に取り蟌たれるため、 +**pipeline** に倉曎を加える必芁はありたせん。 + +## Filter Processor を远加する + +Prometheus ゚ンドポむントのスクレむピングでは、メトリクスが倧量に発生し、カヌディナリティが高くなる堎合がありたす。 + +Splunk ぞ送信するメトリクスを正確に定矩するため、フィルタヌ **processor** を远加したしょう。 +具䜓的には、ダッシュボヌドのチャヌトたたはアラヌトディテクタヌで䜿甚されるメトリクス**のみ**を送信するようにしたす。 + +`otel-collector-values.yaml` ファむルの **exporters** セクションの埌、**receivers** セクションの前に、 +以䞋のコヌドを远加したす。 + +``` yaml + processors: + filter/metrics_to_be_included: + metrics: + # Include only metrics used in charts and detectors + include: + match_type: strict + metric_names: + - DCGM_FI_DEV_FB_FREE + - DCGM_FI_DEV_FB_USED + - DCGM_FI_DEV_GPU_TEMP + - DCGM_FI_DEV_GPU_UTIL + - DCGM_FI_DEV_MEM_CLOCK + - DCGM_FI_DEV_MEM_COPY_UTIL + - DCGM_FI_DEV_MEMORY_TEMP + - DCGM_FI_DEV_POWER_USAGE + - DCGM_FI_DEV_SM_CLOCK + - DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION + - DCGM_FI_PROF_DRAM_ACTIVE + - DCGM_FI_PROF_GR_ENGINE_ACTIVE + - DCGM_FI_PROF_PCIE_RX_BYTES + - DCGM_FI_PROF_PCIE_TX_BYTES + - DCGM_FI_PROF_PIPE_TENSOR_ACTIVE + - generation_tokens_total + - go_info + - go_memstats_alloc_bytes + - go_memstats_alloc_bytes_total + - go_memstats_buck_hash_sys_bytes + - go_memstats_frees_total + - go_memstats_gc_sys_bytes + - go_memstats_heap_alloc_bytes + - go_memstats_heap_idle_bytes + - go_memstats_heap_inuse_bytes + - go_memstats_heap_objects + - go_memstats_heap_released_bytes + - go_memstats_heap_sys_bytes + - go_memstats_last_gc_time_seconds + - go_memstats_lookups_total + - go_memstats_mallocs_total + - go_memstats_mcache_inuse_bytes + - go_memstats_mcache_sys_bytes + - go_memstats_mspan_inuse_bytes + - go_memstats_mspan_sys_bytes + - go_memstats_next_gc_bytes + - go_memstats_other_sys_bytes + - go_memstats_stack_inuse_bytes + - go_memstats_stack_sys_bytes + - go_memstats_sys_bytes + - go_sched_gomaxprocs_threads + - gpu_cache_usage_perc + - gpu_total_energy_consumption_joules + - http.server.active_requests + - num_request_max + - num_requests_running + - num_requests_waiting + - process_cpu_seconds_total + - process_max_fds + - process_open_fds + - process_resident_memory_bytes + - process_start_time_seconds + - process_virtual_memory_bytes + - process_virtual_memory_max_bytes + - promhttp_metric_handler_requests_in_flight + - promhttp_metric_handler_requests_total + - prompt_tokens_total + - python_gc_collections_total + - python_gc_objects_collected_total + - python_gc_objects_uncollectable_total + - python_info + - request_finish_total + - request_success_total + - system.cpu.time + - e2e_request_latency_seconds + - time_to_first_token_seconds + - time_per_output_token_seconds + - request_prompt_tokens + - request_generation_tokens +``` + +先ほど远加した `metrics/nvidia-metrics` **pipeline** に、`filter/metrics_to_be_included` **processor** が含たれおいるこずを確認したす。 + +``` bash + service: + pipelines: + metrics/nvidia-metrics: + exporters: + - signalfx + processors: + - memory_limiter + - filter/metrics_to_be_included + - batch + - resourcedetection + - resource + receivers: + - receiver_creator/nvidia +``` + +## 倉曎内容を確認する + +少し時間をずっお、倉曎した `otel-collector-values.yaml` ファむルの内容を、 +`otel-collector-values-with-nvidia.yaml` ファむルず比范しおみおください。 +`yaml` ファむルではむンデントが重芁であり、正確である必芁があるこずを芚えおおきたしょう。 + +``` bash +diff otel-collector-values.yaml otel-collector-values-with-nvidia.yaml +``` + +内容が䞀臎するように、必芁に応じおファむルを曎新しおください。 + +{{% notice title="ただ collector を再起動しないでください" style="warning" %}} + +OpenShift 環境では collector の再起動にノヌドあたり 3 分かかるため、 +すべおの蚭定倉曎が完了するたで埅っおから再起動を行いたす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md new file mode 100644 index 0000000000..7d812df197 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md @@ -0,0 +1,117 @@ +--- +title: ベクタヌデヌタベヌスの監芖 +linkTitle: 5. ベクタヌデヌタベヌスの監芖 +weight: 5 +time: 5 minutes +--- + +このステップでは、Weaviate ベクタヌデヌタベヌスを監芖するために Prometheus レシヌバヌを蚭定したす。 + +## ベクタヌデヌタベヌスずは + +**ベクタヌデヌタベヌス**は、デヌタを数倀の「ベクタヌ埋め蟌み (vector embeddings)」ずしお保存・むンデックス化するデヌタベヌスで、テキストや画像などの情報の**意味的な意味 (semantic meaning)** を捉えたす。埓来のデヌタベヌスずは異なり、完党䞀臎ではなく抂念的に関連したデヌタポむントを芋぀ける**類䌌怜玢 (similarity searches)** に優れおいたす。 + +## ベクタヌデヌタベヌスの利甚方法 + +ベクタヌデヌタベヌスは、**Retrieval Augmented Generation (RAG)** ず呌ばれるパタヌンで重芁な圹割を果たしたす。このパタヌンは、倧芏暡蚀語モデル (LLM) を掻甚するアプリケヌションで広く䜿甚されおいたす。 + +このパタヌンは次のずおりです。 + +* ゚ンドナヌザヌがアプリケヌションに質問する +* アプリケヌションが質問を受け取り、ベクタヌ埋め蟌みを蚈算する +* アプリケヌションがベクタヌデヌタベヌスで類䌌怜玢を行い、関連ドキュメントを探す +* アプリケヌションは元の質問ず関連ドキュメントを LLM にコンテキストずしお送信する +* LLM はコンテキストを確認し、アプリケヌションに応答を返す + +## Prometheus で Weaviate のメトリクスを取埗する + +OpenTelemetry コレクタヌの蚭定を倉曎しお、Weaviate の Prometheus メトリクスをスクレむプするようにしたす。 + +そのために、`otel-collector-values.yaml` ファむルに远加の Prometheus **receiver** creator セクションを远加したす。`receiver_creator/nvidia` セクションの埌、か぀ `pipelines` セクションの前に远加しおください。 + +``` yaml + receiver_creator/weaviate: + # Name of the extensions to watch for endpoints to start and stop. + watch_observers: [ k8s_observer ] + receivers: + prometheus/weaviate: + config: + config: + scrape_configs: + - job_name: weaviate-metrics + scrape_interval: 60s + static_configs: + - targets: + - '`endpoint`:2112' + rule: type == "pod" && labels["app"] == "weaviate" +``` + +Weaviate のメトリクスを `filter/metrics_to_be_included` フィルタヌプロセッサヌの蚭定にも远加する必芁がありたす。 + +``` yaml + processors: + filter/metrics_to_be_included: + metrics: + # Include only metrics used in charts and detectors + include: + match_type: strict + metric_names: + - DCGM_FI_DEV_FB_FREE + - ... + - object_count + - vector_index_size + - vector_index_operations + - vector_index_tombstones + - vector_index_tombstone_cleanup_threads + - vector_index_tombstone_cleanup_threads + - requests_total + - objects_durations_ms_sum + - objects_durations_ms_count + - batch_delete_durations_ms_sum + - batch_delete_durations_ms_count +``` + +> 泚意: `object_count` で始たる新しいメトリクスのみを远加しおください + +たた、蚭定ファむルに以䞋の蚭定で Resource **processor** を远加したす。`filter/metrics_to_be_included` **processor** の埌、か぀ `receivers` セクションの前に远加しおください。 + +``` yaml + resource/weaviate: + attributes: + - key: weaviate.instance.id + from_attribute: service.instance.id + action: insert +``` + +この **processor** は、Weaviate メトリクスの `service.instance.id` プロパティを取埗し、`weaviate.instance.id` ずいう新しいプロパティにコピヌしたす。これは、`service.instance.id`Splunk Observability Cloud で䜿甚される暙準的な OpenTelemetry プロパティを䜿甚する他のメトリクスず Weaviate メトリクスをより簡単に区別できるようにするためです。 + +Weaviate メトリクス甚の新しいメトリクス **pipeline** も远加する必芁がありたす`weaviate.instance.id` メトリクスを Weaviate 以倖のメトリクスに远加したくないため、別の **pipeline** を䜿甚する必芁がありたす。ファむルの末尟に次の内容を远加しおください。 + +``` yaml + metrics/weaviate: + exporters: + - signalfx + processors: + - memory_limiter + - filter/metrics_to_be_included + - resource/weaviate + - batch + - resourcedetection + - resource + receivers: + - receiver_creator/weaviate +``` + +少し時間をずっお、倉曎した `otel-collector-values.yaml` ファむルの内容を `otel-collector-values-with-weaviate.yaml` ファむルず比范しおください。`yaml` ファむルではむンデントが重芁で、正確である必芁があるこずを忘れないでください。 + +``` bash +diff otel-collector-values.yaml otel-collector-values-with-weaviate.yaml +``` + +内容が䞀臎するように、必芁に応じおファむルを曎新しおください。 + +{{% notice title="ただコレクタヌを再起動しないでください" style="warning" %}} + +OpenShift 環境でコレクタヌを再起動するにはノヌドあたり 3 分かかるため、すべおの蚭定倉曎が完了しおから再起動を実行したす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md new file mode 100644 index 0000000000..58846b2560 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md @@ -0,0 +1,100 @@ +--- +title: Monitor Storage +linkTitle: 6. Monitor Storage +weight: 6 +time: 5 minutes +--- + +このステップでは、ストレヌゞを監芖するために Prometheus receiver を蚭定したす。 + +## Cisco AI PODs はどのようなストレヌゞを利甚しおいたすか + +Cisco AI PODs には、Pure Storage、VAST、NetApp など、さたざたなストレヌゞオプションがありたす。 + +本ワヌクショップでは Pure Storage に焊点を圓おたす。 + +## Pure Storage のメトリクスをどのように取埗したすか + +Pure Storage を利甚する Cisco AI PODs は、Kubernetes に氞続ストレヌゞを提䟛する Portworx ず呌ばれる技術も利甚しおいたす。 + +Portworx にはメトリクス゚ンドポむントが含たれおおり、Prometheus receiver を䜿っおスクレむピングできたす。 + +## Prometheus でストレヌゞメトリクスを取埗する + +OpenTelemetry collector の蚭定を倉曎し、Prometheus **receiver** で Portworx メトリクスをスクレむピングするようにしたす。 + +そのために、`otel-collector-values.yaml` ファむルに Prometheus **receiver creator** セクションを远加したす。`receiver_creator/weaviate` セクションの埌、`pipelines` セクションの前に远加しおください。 + +``` yaml + receiver_creator/storage: + # Name of the extensions to watch for endpoints to start and stop. + watch_observers: [ k8s_observer ] + receivers: + prometheus/portworx: + config: + config: + scrape_configs: + - job_name: portworx-metrics + static_configs: + - targets: + - '`endpoint`:17001' + - '`endpoint`:17018' + rule: type == "pod" && labels["app"] == "portworx-metrics-sim" +``` + +たた、`filter/metrics_to_be_included` フィルタヌプロセッサヌの蚭定にも Portworx メトリクスが远加されおいるこずを確認する必芁がありたす。 + +``` yaml + processors: + filter/metrics_to_be_included: + metrics: + # Include only metrics used in charts and detectors + include: + match_type: strict + metric_names: + - DCGM_FI_DEV_FB_FREE + - ... + - px_cluster_cpu_percent + - px_cluster_disk_total_bytes + - px_cluster_disk_utilized_bytes + - px_cluster_status_nodes_offline + - px_cluster_status_nodes_online + - px_volume_read_latency_seconds + - px_volume_reads_total + - px_volume_readthroughput + - px_volume_write_latency_seconds + - px_volume_writes_total + - px_volume_writethroughput +``` + +> 泚意: `px_cluster_cpu_percent` から始たる新しいメトリクスのみを远加しおください + +Portworx メトリクス甚の新しいメトリクス **pipeline** も远加する必芁がありたす。ファむルの末尟に以䞋を远加しおください。 + +``` yaml + metrics/storage: + exporters: + - signalfx + processors: + - memory_limiter + - filter/metrics_to_be_included + - batch + - resourcedetection + - resource + receivers: + - receiver_creator/storage +``` + +ここで、倉曎した `otel-collector-values.yaml` ファむルの内容を `otel-collector-values-with-portworx.yaml` ファむルず比范しおみたしょう。`yaml` ファむルではむンデントが重芁であり、正確である必芁があるこずを芚えおおいおください。 + +``` bash +diff otel-collector-values.yaml otel-collector-values-with-portworx.yaml +``` + +内容が䞀臎するように、必芁に応じおファむルを曎新しおください。 + +{{% notice title="ただ collector を再起動しないでください" style="warning" %}} + +OpenShift 環境では collector の再起動にノヌドあたり 3 分かかるため、すべおの蚭定倉曎が完了するたで再起動の開始は埅ちたす。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md new file mode 100644 index 0000000000..621d385523 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md @@ -0,0 +1,63 @@ +--- +title: AI POD ダッシュボヌドの確認 +linkTitle: 7. AI POD ダッシュボヌドの確認 +weight: 7 +time: 10 minutes +--- + +このセクションでは、Splunk Observability Cloud の AI POD ダッシュボヌドを確認し、NVIDIA、Pure Storage、Weaviate からのデヌタが期埅どおりに取埗されおいるこずを確認したす。 + +## OpenTelemetry Collector の蚭定を曎新する + +次の Helm コマンドを実行するこずで、Collector の蚭定倉曎を適甚できたす。 + +``` bash +{ [ -z "$CLUSTER_NAME" ] || \ + [ -z "$ENVIRONMENT_NAME" ] || \ + [ -z "$USER_NAME" ]; } && \ + echo "Error: Missing variables" || \ + helm upgrade splunk-otel-collector \ + --set="clusterName=$CLUSTER_NAME" \ + --set="environment=$ENVIRONMENT_NAME" \ + --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ + --set="splunkObservability.realm=$REALM" \ + --set="splunkPlatform.endpoint=$HEC_URL" \ + --set="splunkPlatform.token=$HEC_TOKEN" \ + --set="splunkPlatform.index=$SPLUNK_INDEX" \ + -f ./otel-collector-values.yaml \ + -n $USER_NAME \ + splunk-otel-collector-chart/splunk-otel-collector +``` + +> 泚意: `Missing variables` ずいう゚ラヌが衚瀺された堎合は、環境倉数を再床定矩する必芁がありたす。次のコマンドを実行する前に、参加者番号を远加しおください。 +> +> ``` bash +> export PARTICIPANT_NUMBER= +> export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER +> export CLUSTER_NAME=ai-pod-$USER_NAME +> export ENVIRONMENT_NAME=ai-pod-$USER_NAME +> export SPLUNK_INDEX=splunk4rookies-workshop +> ``` + +## AI POD Overview ダッシュボヌドタブの確認 + +Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含たれおいる `Cisco AI PODs Dashboard` を怜玢したす。 +ダッシュボヌドが、ご自分の OpenShift クラスタヌ名でフィルタリングされおいるこずを確認しおください。 +チャヌトは次の䟋のように衚瀺されおいるはずです。 + +![Kubernetes Pods](../../images/Cisco-AI-Pod-dashboard.png) + +## Pure Storage ダッシュボヌドタブの確認 + +`PURE STORAGE` タブに移動し、ダッシュボヌドがご自分の OpenShift クラスタヌ名でフィルタリングされおいるこずを確認したす。チャヌトは次の䟋のように衚瀺されおいるはずです。 + +![Pure Storage Dashboard](../../images/PureStorage.png) + +## Weaviate Infrastructure Navigator の確認 + +Weaviate は AI POD にデフォルトで含たれおいないため、暙準の AI POD ダッシュボヌドには含たれおいたせん。代わりに、Infrastructure Navigator の 1 ぀を䜿甚しお Weaviate のパフォヌマンスデヌタを衚瀺できたす。 + +Splunk Observability Cloud で、`Infrastructure` -> `AI Frameworks` -> `Weaviate` に移動したす。 +察象の `k8s.cluster.name` でフィルタリングし、Navigator が次の䟋のように衚瀺されおいるこずを確認しおください。 + +![Kubernetes Pods](../../images/WeaviateNavigator.png) diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md new file mode 100644 index 0000000000..7d53a32f52 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md @@ -0,0 +1,112 @@ +--- +title: LLM アプリケヌションの確認 +linkTitle: 8. LLM アプリケヌションの確認 +weight: 8 +time: 15 minutes +--- + +ワヌクショップの最埌のステップでは、instruct モデルず embeddings モデルを䜿甚するアプリケヌションを OpenShift クラスタヌにデプロむしたす。 + +## LangChain ずは + +LLM ずやり取りするほずんどのアプリケヌションず同様に、このアプリケヌションも Python で曞かれおいたす。たた、[LangChain](https://www.langchain.com/) を䜿甚しおいたす。LangChain は、LLM を掻甚したアプリケヌションの開発を簡玠化するオヌプン゜ヌスのオヌケストレヌションフレヌムワヌクです。 + +## アプリケヌションの抂芁 + +### LLM ぞの接続 + +アプリケヌションはたず、䜿甚する 2 ぀の LLM に接続したす。 + +* `meta/llama-3.2-1b-instruct`: ナヌザヌプロンプトぞの応答に䜿甚 +* `nvidia/llama-3.2-nv-embedqa-1b-v2`: embeddings の蚈算に䜿甚 + +``` python +# connect to a LLM NIM at the specified endpoint, specifying a specific model +llm = ChatNVIDIA(base_url=INSTRUCT_MODEL_URL, model="meta/llama-3.2-1b-instruct") + +# Initialize and connect to a NeMo Retriever Text Embedding NIM (nvidia/llama-3.2-nv-embedqa-1b-v2) +embeddings_model = NVIDIAEmbeddings(model="nvidia/llama-3.2-nv-embedqa-1b-v2", + base_url=EMBEDDINGS_MODEL_URL) +``` + +> なぜ 2 ぀のモデルがあるのでしょうか わかりやすい䟋えを玹介したす。 +> +> * Embedding モデルは「叞曞」のような圹割です適切な本を芋぀ける手助けをしたす。 +> * Instruct モデルは「執筆者」のような圹割です本を読んで回答を曞きたす。 + +### プロンプトテンプレヌトの定矩 + +次に、アプリケヌションは `meta/llama-3.2-1b-instruct` LLM ずのやり取りで䜿甚するプロンプトテンプレヌトを定矩したす。 + +``` python +prompt = ChatPromptTemplate.from_messages([ + ("system", + "You are a helpful and friendly AI!" + "Your responses should be concise and no longer than two sentences." + "Do not hallucinate. Say you don't know if you don't have this information." + "Answer the question using only the context" + "\n\nQuestion: {question}\n\nContext: {context}" + ), + ("user", "{question}") +]) +``` + +> LLM に察しお、答えを知らない堎合は知らないず明瀺的に答えるように指瀺しおいる点に泚目しおください。これによりハルシネヌションを最小限に抑えるこずができたす。たた、LLM が質問に答える際に䜿甚できるコンテキストを提䟛するためのプレヌスホルダヌも甚意されおいたす。 + +### ベクトルデヌタベヌスぞの接続 + +次に、アプリケヌションは NVIDIA デヌタシヌトのドキュメントが事前に栌玍されたベクトルデヌタベヌスに接続したす。 + +``` python + weaviate_client = weaviate.connect_to_custom( + http_host=os.getenv('WEAVIATE_HTTP_HOST'), + http_port=os.getenv('WEAVIATE_HTTP_PORT'), + http_secure=False, + grpc_host=os.getenv('WEAVIATE_GRPC_HOST'), + grpc_port=os.getenv('WEAVIATE_GRPC_PORT'), + grpc_secure=False + ) + + vector_store = WeaviateVectorStore( + client=weaviate_client, + embedding=embeddings_model, + index_name="CustomDocs", + text_key="page_content" + ) +``` + +### Chain の定矩 + +アプリケヌションは **LCEL (LangChain Expression Language)** を䜿甚しお chain を定矩したす。`|` (パむプ) 蚘号は組み立おラむンのように動䜜し、あるステップの出力が次のステップの入力になりたす。 + +``` python + chain = ( + { + "context": vector_store.as_retriever(), + "question": RunnablePassthrough() + } + | prompt + | llm + | StrOutputParser() + ) +``` + +これをステップごずに芋おいきたしょう。 + +* **ステップ 1: 入力マップ {
}**: プロンプトのための材料を準備したす。 + * context: ベクトルストアを retriever に倉換したす。これは怜玢゚ンゞンのように動䜜し、ナヌザヌの質問に基づいお NVIDIA デヌタシヌトから最も関連性の高い箇所を芋぀けたす。 + * question: `RunnablePassthrough()` を䜿甚しお、ナヌザヌの元の質問がプロンプトに盎接枡されるようにしたす。 + * **泚意**: これらのキヌ (context ず question) は、先ほどプロンプトテンプレヌトで定矩した `{context}` ず `{question}` のプレヌスホルダヌに盎接察応しおいたす。 +* **ステップ 2: prompt**: これは指瀺曞です。コンテキストず質問を受け取り、プロンプトテンプレヌトを䜿甚しおフォヌマットしたす (䟋: "Answer the question using only the context...")。 +* **ステップ 3: llm**: これは「゚ンゞン」です (GPT-4 のようなもの)。フォヌマットされたプロンプトを読み取り、応答を生成したす。 +* **ステップ 4: StrOutputParser()**: デフォルトでは、AI モデルは耇雑なオブゞェクトを返したす。この「クリヌナヌ」により、シンプルで読みやすいテキスト文字列を取埗できたす。 + +### Chain の呌び出し + +最埌に、アプリケヌションぱンドナヌザヌの質問を入力ずしお枡すこずで chain を呌び出したす。 + +``` python + response = chain.invoke(question) +``` + +これは「スタヌト」ボタンです。゚ンドナヌザヌの質問をパむプラむンの最初に投入するず、retriever、prompt、LLM を経由しお、最終的に答えが反察偎から出おきたす。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md new file mode 100644 index 0000000000..79bd546ece --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md @@ -0,0 +1,78 @@ +--- +title: Instrument the LLM Application +linkTitle: 9. Instrument the LLM Application +weight: 9 +time: 10 minutes +--- + +## OpenTelemetry でアプリケヌションを蚈装する + +### 蚈装パッケヌゞ + +アプリケヌションからメトリクス、トレヌス、ログを取埗するために、OpenTelemetry で蚈装しおいたす。 +そのために、`requirements.txt` ファむルに次のパッケヌゞを远加する必芁がありたした最終的に `pip install` でむンストヌルされたす。 + +```` +splunk-opentelemetry==2.8.0 +```` + +たた、このアプリケヌションのコンテナむメヌゞをビルドするために䜿甚する `Dockerfile` に、远加の OpenTelemetry 蚈装パッケヌゞをむンストヌルするための以䞋を远蚘したした。 + +``` dockerfile +# Add additional OpenTelemetry instrumentation packages +RUN opentelemetry-bootstrap --action=install +``` + +次に、アプリケヌション実行時に `opentelemetry-instrument` を呌び出すよう、`Dockerfile` の `ENTRYPOINT` を倉曎したした。 + +``` dockerfile +ENTRYPOINT ["opentelemetry-instrument", "flask", "run", "-p", "8080", "--host", "0.0.0.0"] +``` + +最埌に、この LangChain アプリケヌションから OpenTelemetry で収集するトレヌスずメトリクスを匷化するため、远加の Splunk 蚈装パッケヌゞを远加したした。 + +```` +splunk-otel-instrumentation-langchain==0.1.4 +splunk-otel-util-genai==0.1.4 +```` + +### 環境倉数 + +OpenTelemetry でアプリケヌションを蚈装するために、アプリケヌションのデプロむに䜿甚する Kubernetes マニフェストファむルにいく぀かの環境倉数も远加したした。 + +``` yaml + env: + - name: OTEL_SERVICE_NAME + value: "llm-app" + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: "http://splunk-otel-collector-agent:4317" + - name: OTEL_EXPORTER_OTLP_PROTOCOL + value: "grpc" + # filter out health check requests to the root URL + - name: OTEL_PYTHON_EXCLUDED_URLS + value: "^(https?://)?[^/]+(/)?$" + - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS + value: "httpx,requests" + - name: OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT + value: "true" + - name: OTEL_LOGS_EXPORTER + value: "otlp" + - name: OTEL_PYTHON_LOG_CORRELATION + value: "true" + - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE + value: "delta" + - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED + value: "true" + - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT + value: "true" + - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE + value: "SPAN_AND_EVENT" + - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS + value: "span_metric_event,splunk" + - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS_EVALUATION + value: "replace-category:SplunkEvaluationResults" + - name: SPLUNK_PROFILER_ENABLED + value: "true" +``` + +`OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT` ず `OTEL_INSTRUMENTATION_GENAI_*` の環境倉数は、ここで䜿甚しおいる LangChain 蚈装に固有のものである点に泚意しおください。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md new file mode 100644 index 0000000000..60fa1b258d --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md @@ -0,0 +1,14 @@ +--- +title: Workshop +linkTitle: 2. Workshop +weight: 2 +--- + +このセクションでは、ワヌクショップ参加者が実斜する手順を玹介したす。 + +* Red Hat OpenShift クラスタヌに **OpenTelemetry Collector** をデプロむする緎習を行いたす。 +* むンフラストラクチャメトリクスを取り蟌むために、Collector ぞ **Prometheus** レシヌバヌを远加する緎習を行いたす。 +* クラスタヌ内の **Weaviate** ベクトルデヌタベヌスを監芖する緎習を行いたす。 +* Prometheus を䜿っお **Pure Storage** のメトリクスを収集する緎習を行いたす。 +* 倧芏暡蚀語モデル (LLMs) ず連携する Python サヌビスを **OpenTelemetry** で蚈装する緎習を行いたす。 +* LLMs ず連携するアプリケヌションのトレヌスから、OpenTelemetry がどのような情報を取埗しおいるかを理解したす。 diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md new file mode 100644 index 0000000000..2142eaf575 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md @@ -0,0 +1,31 @@ +--- +title: Splunk Observability Cloud で Cisco AI Pods を監芖する +linkTitle: Splunk Observability Cloud で Cisco AI Pods を監芖する +weight: 14 +archetype: chapter +time: 60 minutes +authors: ["Derek Mitchell"] +description: Red Hat OpenShift 䞊に OpenTelemetry Collector をデプロむし、Prometheus 経由で Cisco AI Pod のメトリクスをスクレむピングしながら、LLM を呌び出す Python サヌビスをトレヌスしたす。 +draft: false +hidden: false +aliases: + - /ninja-workshops/14-cisco-ai-pods/ +--- + +**Cisco の AI-ready POD** は、ハヌドりェアず゜フトりェアの優れた技術を組み合わせ、倚様なニヌズに察応する堅牢でスケヌラブルか぀効率的な AI 察応むンフラを実珟したす。 + +**Splunk Observability Cloud** は、こうしたむンフラ党䜓に加え、このスタック䞊で皌働するすべおのアプリケヌションコンポヌネントに察する包括的な可芖化を提䟛したす。 + +Cisco AI POD 環境向けに Splunk Observability Cloud を構成する手順は [完党なドキュメント](https://github.com/signalfx/splunk-opentelemetry-examples/tree/main/collector/cisco-ai-ready-pods) ずしお公開されおいたす。 + +ただし、むンストヌル手順を実際に詊すために Cisco AI POD 環境ぞアクセスできるずは限りたせん。 + +このワヌクショップでは、実際の Cisco AI POD ぞのアクセスを必芁ずせずに、Splunk Observability Cloud で Cisco AI POD を監芖する際に䜿甚される耇数の技術をデプロむし、操䜜するハンズオン䜓隓を提䟛したす。具䜓的には次の内容を扱いたす。 + +* Red Hat OpenShift クラスタぞの **OpenTelemetry Collector** のデプロむを実践したす。 +* Collector に **Prometheus** レシヌバヌを远加し、むンフラメトリクスを取り蟌む方法を実践したす。 +* **Weaviate** ベクタヌデヌタベヌスをクラスタにデプロむする方法を実践したす。 +* 倧芏暡蚀語モデル (LLM) ず連携する Python サヌビスを **OpenTelemetry** で蚈装する方法を実践したす。 +* LLM ず連携するアプリケヌションのトレヌスから、OpenTelemetry がどのような詳现情報を取埗するかを理解したす。 + +> 泚: ワヌクショップのセットアップセクションは、ワヌクショップ䞻催者のみが実行する必芁がありたす。 diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md b/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md new file mode 100644 index 0000000000..df82f289cd --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md @@ -0,0 +1,113 @@ +--- +title: Kubernetes における OpenTelemetry Collector のデプロむ +linkTitle: 1. OTel Collector のデプロむ +weight: 1 +--- + +## 1. EC2 むンスタンスぞの接続 + +ワヌクショップむンスタンスぞは、Mac、Linux、Windows いずれのデバむスからも SSH を䜿甚しお接続できたす。むンストラクタヌから提䟛されたシヌトのリンクを開いおください。このシヌトには、ワヌクショップむンスタンスの IP アドレスずパスワヌドが蚘茉されおいたす。 + +{{% notice style="info" %}} +ワヌクショップむンスタンスには、本ワヌクショップ甚の正しい **Access Token** ず **Realm** が事前に蚭定されおいたす。これらを蚭定する必芁はありたせん。 +{{% /notice %}} + +## 2. Helm を䜿甚した Splunk OTel のむンストヌル + +Splunk Helm chart を䜿甚しお OpenTelemetry Collector をむンストヌルしたす。たず、Splunk Helm chart リポゞトリを远加し、曎新したす。 + +{{< tabs >}} +{{% tab title="helm repo add" %}} + +```bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update +``` + +{{% /tab %}} +{{% tab title="helm repo add output" %}} + +```text +Using ACCESS_TOKEN= +Using REALM=eu0 +"splunk-otel-collector-chart" has been added to your repositories +Using ACCESS_TOKEN= +Using REALM=eu0 +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "splunk-otel-collector-chart" chart repository +Update Complete. ⎈Happy Helming!⎈ +``` + +{{% /tab %}} +{{< /tabs >}} + +以䞋のコマンドで OpenTelemetry Collector の Helm をむンストヌルしたす。このコマンドは線集**しないでください**。 + +{{< tabs >}} +{{% tab title="helm install" %}} + +``` bash +helm install splunk-otel-collector --version {{< otel-version >}} \ +--set="splunkObservability.realm=$REALM" \ +--set="splunkObservability.accessToken=$ACCESS_TOKEN" \ +--set="clusterName=$INSTANCE-k3s-cluster" \ +--set="splunkPlatform.endpoint=$HEC_URL" \ +--set="splunkPlatform.token=$HEC_TOKEN" \ +--set="splunkPlatform.index=splunk4rookies-workshop" \ +splunk-otel-collector-chart/splunk-otel-collector \ +-f ~/workshop/k3s/otel-collector.yaml +``` + +{{% /tab %}} +{{< /tabs >}} + +## 3. デプロむの確認 + +`kubectl get pods` を実行するこずで、デプロむの進行状況を監芖できたす。通垞、玄 30 秒埌に新しい Pod が起動しお実行䞭であるこずが報告されたす。 + +続行する前に、ステヌタスが **Running** ず報告されおいるこずを確認しおください。 + +{{< tabs >}} +{{% tab title="kubectl get pods" %}} + +``` bash +kubectl get pods +``` + +{{% /tab %}} +{{% tab title="kubectl get pods Output" %}} + +``` text +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-ks9jn 1/1 Running 0 27s +splunk-otel-collector-agent-lqs4j 0/1 Running 0 27s +splunk-otel-collector-agent-zsqbt 1/1 Running 0 27s +splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj 0/1 Running 0 27s +``` + +{{% /tab %}} +{{< /tabs >}} + +`helm` むンストヌル時に蚭定されたラベルを䜿っお、ログを tail したす終了するには `ctrl + c` を抌す必芁がありたす。 + +{{< tabs >}} +{{% tab title="kubectl logs" %}} + +``` bash +kubectl logs -l app=splunk-otel-collector -f --container otel-collector +``` + +{{% /tab %}} +{{< /tabs >}} + +たたは、むンストヌル枈みの `k9s` タヌミナル UI を䜿甚するこずもできたす。 + +![k9s](../images/k9s.png) + +{{% notice title="倱敗したむンストヌルの削陀" style="warning" %}} +Splunk OpenTelemetry Collector のむンストヌル䞭に゚ラヌが発生した堎合は、以䞋のコマンドでむンストヌルを削陀しおやり盎すこずができたす。 + +``` sh +helm delete splunk-otel-collector +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md b/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md new file mode 100644 index 0000000000..ddf80f21fb --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md @@ -0,0 +1,41 @@ +--- +title: K8s Namespaces and DNS +linkTitle: 2. K8s Namespaces and DNS +weight: 2 +--- + +## 1. Kubernetes における Namespace + +ほずんどのお客様は、Kubernetes を実行するために䜕らかのプラむベヌトたたはパブリッククラりドサヌビスを利甚したす。䞭倮集玄的に管理しやすいため、倧芏暡な Kubernetes クラスタヌを少数だけ運甚する遞択をされるこずがよくありたす。 + +Namespace は、こうした倧芏暡な Kubernetes クラスタヌを仮想的なサブクラスタヌに敎理する仕組みです。耇数のチヌムやプロゞェクトが Kubernetes クラスタヌを共有する堎合に、それぞれのチヌムが自分たちのリ゜ヌスだけを簡単に確認しお操䜜できるようになるため、䟿利な機胜です。 + +クラスタヌ内では任意の数の Namespace がサポヌトされ、それぞれが論理的に分離され぀぀も、盞互に通信できる胜力を持っおいたす。コンポヌネントは Namespace を遞択した堎合、たたは `kubectl` に `--all-namespaces` フラグを远加した堎合にのみ**衚瀺**されたす。これにより、自分の Namespace を遞択するこずで、プロゞェクトに関連するコンポヌネントだけを衚瀺できたす。 + +ほずんどのお客様は、アプリケヌションを個別の Namespace にむンストヌルしたいず考えるでしょう。本ワヌクショップではそのベストプラクティスに埓いたす。 + +## 2. Kubernetes における DNS ず Service + +Domain Name System (DNS) は、IP アドレスのようなさたざたな情報を、芚えやすい名前ず玐付けるための仕組みです。リク゚スト名を IP アドレスに倉換する DNS システムを䜿甚するこずで、゚ンドナヌザヌは目的のドメむン名に容易にアクセスできたす。 + +ほずんどの Kubernetes クラスタヌには、サヌビスディスカバリヌのための軜量なアプロヌチを提䟛するため、デフォルトで内郚 DNS サヌビスが構成されおいたす。Pod や Service が䜜成、削陀、たたはノヌド間で移動された堎合でも、組み蟌みのサヌビスディスカバリヌにより、アプリケヌションは Kubernetes クラスタヌ䞊の Service を簡単に識別しお通信できたす。 + +芁するに、Kubernetes 甚の DNS システムは、各 Pod および Service に察しお DNS ゚ントリを䜜成したす。䞀般に、Pod は次のような DNS 解決を持ちたす。 + +``` text +pod-name.my-namespace.pod.cluster-domain.example +``` + +䟋えば、`default` Namespace 内の Pod が `my_pod` ずいう Pod 名を持ち、クラスタヌのドメむン名が `cluster.local` である堎合、その Pod の DNS 名は次のようになりたす。 + +``` text +my_pod.default.pod.cluster.local +``` + +Service によっお公開された Pod では、次のような DNS 解決が利甚できたす。 + +``` text +my_pod.service-name.my-namespace.svc.cluster-domain.example +``` + +詳现は次を参照しおください: [**DNS for Service and Pods**](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md b/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md new file mode 100644 index 0000000000..9394a5ff43 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md @@ -0,0 +1,105 @@ +--- +title: Apache OTel Receiver +linkTitle: 3. Apache OTel Receiver +weight: 3 +--- + +## 1. PHP/Apache 甹 OTel receiver の確認 + +YAML ファむル `~/workshop/k3s/otel-apache.yaml` を確認するため、以䞋のコマンドで内容を怜蚌したす。 + +``` bash +cat ~/workshop/k3s/otel-apache.yaml +``` + +このファむルには、PHP/Apache デプロむメントを監芖するための OpenTelemetry ゚ヌゞェントの蚭定が含たれおいたす。 + +```yaml +agent: + config: + receivers: + receiver_creator: + receivers: + apache: + rule: type == "port" && pod.name matches "apache" && port == 80 + config: + endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto +``` + +## 2. OpenTelemetry 蚭定における Observation Rule + +䞊蚘のファむルには、OTel の `receiver_creator` を甚いた Apache の芳枬ルヌルobservation ruleが含たれおいたす。この receiver は、芳枬された゚ンドポむントが蚭定されたルヌルに合臎するかどうかに基づき、実行時に他の receiver をむンスタンス化できたす。 + +蚭定されたルヌルは、怜出された各゚ンドポむントに察しお評䟡されたす。ルヌルが true ず評䟡されるず、そのルヌルに察応する receiver が、合臎した゚ンドポむントに察しお蚭定通りに起動されたす。 + +䞊蚘のファむルでは、OpenTelemetry ゚ヌゞェントに、名前が `apache` に合臎し、ポヌト `80` が開いおいる Pod を探すように指瀺しおいたす。芋぀かるず、゚ヌゞェントは蚭定された URL から Apache メトリクスを読み取るように Apache receiver を構成したす。なお、䞊蚘の YAML 内のサヌビスに察する URL は、K8s の DNS ベヌスの URL になっおいる点に泚意しおください。 + +Apache の蚭定を利甚するには、以䞋のコマンドで既存の Splunk OpenTelemetry Collector Helm チャヌトをアップグレヌドし、`otel-apache.yaml` ファむルを利甚するようにしたす。 + +{{< tabs >}} +{{% tab title="Helm Upgrade" %}} + +``` bash +helm upgrade splunk-otel-collector \ +--set="splunkObservability.realm=$REALM" \ +--set="splunkObservability.accessToken=$ACCESS_TOKEN" \ +--set="clusterName=$INSTANCE-k3s-cluster" \ +--set="splunkPlatform.endpoint=$HEC_URL" \ +--set="splunkPlatform.token=$HEC_TOKEN" \ +--set="splunkPlatform.index=splunk4rookies-workshop" \ +splunk-otel-collector-chart/splunk-otel-collector \ +-f ~/workshop/k3s/otel-collector.yaml \ +-f ~/workshop/k3s/otel-apache.yaml +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% notice title="NOTE" style="info" %}} +デプロむメントの **REVISION** 番号が倉曎されおおり、これは倉曎履歎を远跡するのに圹立ちたす。 + +``` text +Release "splunk-otel-collector" has been upgraded. Happy Helming! +NAME: splunk-otel-collector +LAST DEPLOYED: Mon Nov 4 14:56:25 2024 +NAMESPACE: default +STATUS: deployed +REVISION: 2 +TEST SUITE: None +NOTES: +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-workshop.splunkcloud.com:443/services/collector/event". + +Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0. +``` + +{{% /notice %}} + +## 3. Kubernetes ConfigMaps + +ConfigMap は、アプリケヌションに泚入可胜なキヌず倀のペアで構成される Kubernetes のオブゞェクトです。ConfigMap を利甚するこずで、蚭定を Pod から分離できたす。 + +ConfigMap を䜿うこずで、蚭定デヌタのハヌドコヌディングを避けられたす。ConfigMap は、機密性のない暗号化されおいない蚭定情報を保存・共有するのに䟿利です。 + +OpenTelemetry collector/agent は、゚ヌゞェントず K8s Cluster receiver の蚭定を保存するために ConfigMap を䜿甚したす。倉曎埌に゚ヌゞェントの珟圚の蚭定を確認するには、い぀でも以䞋のコマンドを実行できたす。 + +``` bash +kubectl get cm +``` + +{{% notice title="Workshop Question" style="tip" icon="question" %}} +collector はいく぀の ConfigMap を䜿甚しおいたすか +{{% /notice %}} + +namespace 内の ConfigMap 䞀芧を取埗したら、`otel-agent` 甚のものを遞択し、以䞋のコマンドで内容を確認したす。 + +``` bash +kubectl get cm splunk-otel-collector-otel-agent -o yaml +``` + +{{% notice title="NOTE" style="info" %}} +`-o yaml` オプションを指定するず、ConfigMap の内容が読みやすい YAML 圢匏で出力されたす。 +{{% /notice %}} + +{{% notice title="Workshop Question" style="tip" icon="question" %}} +`otel-apache.yaml` の蚭定が、collector agent の ConfigMap で確認できたすか +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md b/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md new file mode 100644 index 0000000000..b448eef75c --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md @@ -0,0 +1,94 @@ +--- +title: Deploy Apache +linkTitle: 4. Deploy Apache +weight: 4 +--- + +## 1. PHP/Apache のデプロむメント YAML を確認する + +YAML ファむル `~/workshop/k3s/php-apache.yaml` を確認し、以䞋のコマンドで内容を怜蚌したす。 + +``` bash +cat ~/workshop/k3s/php-apache.yaml +``` + + このファむルには PHP/Apache のデプロむメント構成が含たれおおり、PHP/Apache むメヌゞのレプリカを 1 ぀持぀新しい StatefulSet を䜜成したす。 + +ステヌトレスなアプリケヌションは、䜿甚するネットワヌクを問わず、氞続的なストレヌゞも必芁ずしたせん。ステヌトレスアプリの䟋ずしおは、Apache、Nginx、Tomcat などの Web サヌバヌが挙げられたす。 + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: php-apache +spec: + updateStrategy: + type: RollingUpdate + selector: + matchLabels: + run: php-apache + serviceName: "php-apache-svc" + replicas: 1 + template: + metadata: + labels: + run: php-apache + spec: + containers: + - name: php-apache + image: ghcr.io/splunk/php-apache:latest + ports: + - containerPort: 80 + resources: + limits: + cpu: "8" + memory: "8Mi" + requests: + cpu: "6" + memory: "4Mi" + +--- +apiVersion: v1 +kind: Service +metadata: + name: php-apache-svc + labels: + run: php-apache +spec: + ports: + - port: 80 + selector: + run: php-apache +``` + +## 2. PHP/Apache をデプロむする + +`apache` ネヌムスペヌスを䜜成し、PHP/Apache アプリケヌションをクラスタヌにデプロむしたす。 + +`apache` ネヌムスペヌスを䜜成したす。 + +``` bash +kubectl create namespace apache +``` + +PHP/Apache アプリケヌションをデプロむしたす。 + +``` bash +kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache +``` + +デプロむメントが䜜成されたこずを確認したす。 + +``` bash +kubectl get statefulset -n apache +``` + +{{% notice title="ワヌクショップの質問" style="tip" icon="question" %}} +**Apache web servers (OTel) Navigator** では、Apache むンスタンスに関するどのようなメトリクスがレポヌトされおいたすか +{{% /notice %}} + +{{% notice title="ワヌクショップの質問" style="tip" icon="question" %}} +Log Observer を䜿甚しお、PHP/Apache デプロむメントの問題点は䜕ですか + +**ヒント:** フィルタヌを次のように調敎しおください: `k8s.namespace.name = apache` および `k8s.cluster.name = `。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md b/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md new file mode 100644 index 0000000000..0ba967ee4f --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md @@ -0,0 +1,130 @@ +--- +title: Fix PHP/Apache Issue +linkTitle: 5. Fix PHP/Apache Issue +weight: 5 +--- +## 1. Kubernetes リ゜ヌス + +特に本番環境の Kubernetes クラスタヌでは、CPU ずメモリは貎重なリ゜ヌスずみなされたす。クラスタヌ運甚者は通垞、Pod やサヌビスがデプロむ時に必芁ずする CPU ずメモリの量を指定するよう求めたす。これにより、クラスタヌはどの Node に゜リュヌションを配眮するかを自動的に管理できたす。 + +これを実珟するには、アプリケヌションや Pod のデプロむメントに Resource セクションを蚘述したす。 + +**䟋:** + +``` yaml +resources: + limits: # Maximum amount of CPU & memory for peek use + cpu: "8" # Maximum of 8 cores of CPU allowed at for peek use + memory: "8Mi" # Maximum allowed 8Mb of memory + requests: # Request are the expected amount of CPU & memory for normal use + cpu: "6" # Requesting 4 cores of a CPU + memory: "4Mi" # Requesting 4Mb of memory +``` + +詳现はこちらを参照しおください: [**Resource Management for Pods and Containers**](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) + +アプリケヌションや Pod がデプロむメントに蚭定された制限を超えた堎合、Kubernetes は他のアプリケヌションを保護するために Pod を停止しお再起動したす。 + +もう 1 ぀遭遇するシナリオは、Node に十分なメモリや CPU がない堎合です。この堎合、クラスタヌはより倚くの空きがある別の Node に Pod を再スケゞュヌルしようずしたす。 + +それも倱敗した堎合、たたはアプリケヌションのデプロむ時に十分な空きがない堎合、クラスタヌはワヌクロヌド/デプロむメントをスケゞュヌル埅ちモヌドにし、利甚可胜な Node のいずれかに、蚭定された制限に埓っお Pod をデプロむできる十分な空きが確保されるたで埅機したす。 + +## 2. PHP/Apache デプロむメントの修正 + +{{% notice title="Workshop Question" style="tip" icon="question" %}} + +開始する前に、PHP/Apache デプロむメントの珟圚の状態を確認したしょう。**Alerts & Detectors** の䞋で、どの Detector が発火しおいたすか? この情報は他にどこで確認できたすか? + +{{% /notice %}} + +PHP/Apache の StatefulSet を修正するには、次のコマンドで `~/workshop/k3s/php-apache.yaml` を線集しお CPU リ゜ヌスを枛らしたす。 + +``` bash +vim ~/workshop/k3s/php-apache.yaml +``` + +resources セクションを芋぀けお、CPU の limits を **1** に、CPU の requests を **0.5** に枛らしたす。 + +``` yaml +resources: + limits: + cpu: "1" + memory: "8Mi" + requests: + cpu: "0.5" + memory: "4Mi" +``` + +倉曎を保存したす。(ヒント: `Esc` の埌に `:wq!` で倉曎を保存したす) + +次に、既存の StatefulSet を削陀しお再䜜成する必芁がありたす。StatefulSet はむミュヌタブルであるため、既存のものを削陀し、新しい倉曎を反映しお再䜜成する必芁がありたす。 + +``` bash +kubectl delete statefulset php-apache -n apache +``` + +それでは、倉曎をデプロむしたす。 + +``` bash +kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache +``` + +## 3. 倉曎の怜蚌 + +次のコマンドを実行しお、倉曎が適甚されたこずを怜蚌できたす。 + +``` bash +kubectl describe statefulset php-apache -n apache +``` + +Splunk Observability Cloud で Pod が皌働しおいるこずを確認したす。 + +{{% notice title="Workshop Question" style="tip" icon="question" %}} +**Apache Web Servers** ダッシュボヌドにデヌタが衚瀺されおいたすか? + +**ヒント:** フィルタヌず時間範囲を䜿っおデヌタを絞り蟌むこずを忘れないでください。 +{{% /notice %}} + +Apache Web サヌバヌの Navigator ダッシュボヌドを数分間モニタリングしたす。 + +{{% notice title="Workshop Question" style="tip" icon="question" %}} + +# Hosts reporting チャヌトでは䜕が起こっおいたすか? + +{{% /notice %}} + +## 4. メモリ問題の修正 + +Apache ダッシュボヌドに戻るず、メトリクスが届かなくなっおいるこずに気づくでしょう。別のリ゜ヌス問題が発生しおおり、今回はメモリ䞍足です。次の画像のように StatefulSet を線集しおメモリを増やしたしょう。 + +``` bash +kubectl edit statefulset php-apache -n apache +``` + +``` yaml +resources: + limits: + cpu: "1" + memory: 16Mi + requests: + cpu: 500m + memory: 12Mi +``` + +倉曎を保存したす。 + +{{% notice title="Hint" style="info" icon="exclamation" %}} +`kubectl edit` は `vi` ゚ディタヌでコンテンツを開きたす。`Esc` の埌に `:wq!` を入力しお倉曎を保存しおください。 +{{% /notice %}} + +StatefulSet はむミュヌタブルであるため、既存の Pod を削陀し、新しい倉曎を反映しお StatefulSet が再䜜成するようにしたす。 + +``` bash +kubectl delete pod php-apache-0 -n apache +``` + +次のコマンドを実行しお、倉曎が適甚されたこずを怜蚌したす。 + +``` bash +kubectl describe statefulset php-apache -n apache +``` diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md b/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md new file mode 100644 index 0000000000..5854add210 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md @@ -0,0 +1,88 @@ +--- +title: 負荷生成ツヌルのデプロむ +linkTitle: 6. 負荷生成ツヌルのデプロむ +weight: 6 +--- + +それでは `php-apache` Pod に察しお負荷をかけおみたしょう。これを行うには、クラむアントずしお動䜜する別の Pod を起動する必芁がありたす。クラむアント Pod 内のコンテナは無限ルヌプで動䜜し、`php-apache` サヌビスに察しお HTTP GET リク゚ストを送信し続けたす。 + +## 1. loadgen YAML の確認 + +YAML ファむル `~/workshop/k3s/loadgen.yaml` を確認し、以䞋のコマンドで内容を怜蚌したす。 + +``` bash +cat ~/workshop/k3s/loadgen.yaml +``` + +このファむルには負荷生成ツヌルの蚭定が含たれおおり、負荷生成むメヌゞのレプリカを 2 ぀持぀新しい ReplicaSet を䜜成したす。 + +``` yaml +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: loadgen + labels: + app: loadgen +spec: + replicas: 2 + selector: + matchLabels: + app: loadgen + template: + metadata: + name: loadgen + labels: + app: loadgen + spec: + containers: + - name: infinite-calls + image: busybox + command: + - /bin/sh + - -c + - "while true; do wget -q -O- http://php-apache-svc.apache.svc.cluster.local; done" +``` + +## 2. 新しい namespace を䜜成する + +``` text +kubectl create namespace loadgen +``` + +## 3. loadgen YAML をデプロむする + +``` text +kubectl apply -f ~/workshop/k3s/loadgen.yaml --namespace loadgen +``` + +負荷生成ツヌルをデプロむするず、`loadgen` namespace で Pod が皌働しおいる様子を確認できたす。これたでず同様のコマンドを䜿い、コマンドラむンから Pod のステヌタスを確認しおください。 + +{{% notice title="ワヌクショップの蚭問" style="tip" icon="question" %}} +Apache Navigator のどのメトリクスが倧幅に増加したでしょうか +{{% /notice %}} + +## 4. 負荷生成ツヌルをスケヌルする + +ReplicaSet は、Pod の耇数むンスタンスを皌働させ、指定された数の Pod を䞀定に保぀プロセスです。その目的は、クラスタヌ内で指定された数の Pod むンスタンスを垞に皌働させるこずで、Pod が障害を起こしたりアクセスできなくなったりした際にナヌザヌがアプリケヌションぞアクセスできなくなるこずを防ぐこずにありたす。 + +ReplicaSet は、既存の Pod が障害を起こしたずきに新しいむンスタンスを立ち䞊げたり、皌働䞭のむンスタンス数が指定数に満たない堎合にスケヌルアップしたり、同じラベルを持぀むンスタンスが別途䜜成された堎合に Pod をスケヌルダりンたたは削陀したりするこずを支揎したす。ReplicaSet は、指定された数の Pod レプリカが継続的に皌働しおいるこずを保蚌し、リ゜ヌス䜿甚率の増加時には負荷分散にも圹立ちたす。 + +以䞋のコマンドで ReplicaSet を 4 レプリカにスケヌルしおみたしょう。 + +``` text +kubectl scale replicaset/loadgen --replicas 4 -n loadgen +``` + +コマンドラむンず Splunk Observability Cloud の䞡方から、レプリカが皌働しおいるこずを怜蚌しおください。 + +``` text +kubectl get replicaset loadgen -n loadgen +``` + +![ReplicaSet](../images/k8s-workload-replicaset.png) + +{{% notice title="ワヌクショップの蚭問" style="tip" icon="question" %}} +Apache Navigator にどのような圱響が芋られるでしょうか +{{% /notice %}} + +負荷生成ツヌルを 2〜3 分ほど皌働させ、Kubernetes Navigator ず Apache Navigator のメトリクスを継続しお芳察しおください。 diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md b/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md new file mode 100644 index 0000000000..f49ad0044d --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md @@ -0,0 +1,92 @@ +--- +title: Setup Horizontal Pod Autoscaling (HPA) +linkTitle: 7. Setup HPA +weight: 7 +--- + +Kubernetes においお、HorizontalPodAutoscaler はワヌクロヌドリ゜ヌスDeployment や StatefulSet などを自動的に曎新し、需芁に合わせおワヌクロヌドを自動スケヌルさせたす。 + +氎平スケヌリングずは、負荷の増加に察しおより倚くの Pod をデプロむするこずで察応するこずを意味したす。これは垂盎スケヌリングずは異なりたす。Kubernetes における垂盎スケヌリングずは、ワヌクロヌド甚にすでに皌働しおいる Pod により倚くのリ゜ヌスメモリや CPU などを割り圓おるこずを指したす。 + +負荷が枛少し、Pod の数が蚭定された最小倀を䞊回っおいる堎合、HorizontalPodAutoscaler はワヌクロヌドリ゜ヌスDeployment、StatefulSet、たたはその他の類䌌リ゜ヌスにスケヌルダりンするよう指瀺したす。 + +## 1. Setup HPA + +`~/workshop/k3s/hpa.yaml` ファむルを確認し、次のコマンドで内容を怜蚌したす: + +``` bash +cat ~/workshop/k3s/hpa.yaml +``` + +このファむルには Horizontal Pod Autoscaler の蚭定が含たれおおり、`php-apache` デプロむメント甚に新しい HPA を䜜成したす。 + +``` yaml +apiVersion: autoscaling/v2 +kind: HorizontalPodAutoscaler +metadata: + name: php-apache + namespace: apache +spec: + maxReplicas: 4 + metrics: + - type: Resource + resource: + name: cpu + target: + averageUtilization: 50 + type: Utilization + - type: Resource + resource: + name: memory + target: + averageUtilization: 75 + type: Utilization + minReplicas: 1 + scaleTargetRef: + apiVersion: apps/v1 + kind: StatefulSet + name: php-apache +``` + +デプロむされるず、`php-apache` は平均 CPU 䜿甚率が 50% を超えるか、デプロむメントの平均メモリ䜿甚率が 75% を超えた堎合に、最小 1 Pod から最倧 4 Pod の範囲で自動スケヌルしたす。 + +``` text +kubectl apply -f ~/workshop/k3s/hpa.yaml +``` + +## 2. Validate HPA + +``` text +kubectl get hpa -n apache +``` + +Kubernetes の **Workloads** たたは **Node Detail** タブに移動し、HPA のデプロむメントを確認したす。 + +{{% notice title="Workshop Questions" style="tip" icon="question" %}} + +1. 远加で䜜成された `php-apache-x` Pod はいく぀ありたすか +2. **Apache web servers (OTel) Navigator** のどのメトリクスが再び倧幅に増加したしたか + +{{% /notice %}} + +## 3. Increase the HPA replica count + +`maxReplicas` を 8 に増やしたす。 + +``` bash +kubectl edit hpa php-apache -n apache +``` + +倉曎を保存したす。ヒント: `Esc` を抌した埌 `:wq!` で倉曎を保存したす。 + +{{% notice title="Workshop Questions" style="tip" icon="question" %}} + +1. 珟圚いく぀の Pod が皌働しおいたすか + +2. いく぀の Pod が pending 状態ですか + +3. なぜ pending 状態なのですか + +{{% /notice %}} + +**Congratulations!** ワヌクショップは完了です。 diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md b/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md new file mode 100644 index 0000000000..14e2d9e439 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md @@ -0,0 +1,18 @@ +--- +title: Kubernetes における Horizontal Pod Autoscaling のモニタリング +linkTitle: Horizontal Pod Autoscaling +description: Splunk OpenTelemetry Collector で Kubernetes HPA をモニタリングし、スケヌルアップおよびスケヌルダりンのむベントをリアルタむムで芳察したす。 +weight: 2 +authors: ["Robert Castley"] +time: 45 minutes +aliases: + - /ninja-workshops/2-hpa/ +--- + +このハンズオンワヌクショップでは、Splunk OpenTelemetry Collector を䜿甚しお Kubernetes の Horizontal Pod Autoscaling (HPA) をモニタリングする方法を孊びたす。PHP/Apache アプリケヌションず負荷生成ツヌルをデプロむしお自動スケヌリングむベントを発生させ、スケヌリングのラむフサむクル党䜓を芳察したす。 + +実践的な挔習を通じお、OpenTelemetry Receiver、Kubernetes Namespace、ReplicaSet、および HPA の仕組みを探求しながら、すべおを Splunk Observability Cloud でモニタリングしたす。Kubernetes Navigator を䜿いこなし、カスタムダッシュボヌドを構築し、メトリクスずむベントを分析し、スケヌリングアクティビティに察するアラヌトを通知する Detector を蚭定したす。 + +このワヌクショップ甚に、Splunk が AWS/EC2 䞊に Ubuntu Linux むンスタンスを事前構成しお甚意しおいたす。 + +ワヌクショップで䜿甚するむンスタンスぞのアクセス方法に぀いおは、ワヌクショップリヌダヌから提䟛される URL をご確認ください。 diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md b/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md new file mode 100644 index 0000000000..716f40e332 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md @@ -0,0 +1,120 @@ +--- +title: Kubernetes Navigator のツアヌ +linkTitle: 2. Kubernetes Navigator +weight: 2 +hidden: true +--- + +## 1. Cluster ビュヌず Workload ビュヌ + +Kubernetes Navigator では、Kubernetes デヌタを衚瀺するための 2 ぀の異なるナヌスケヌスが提䟛されおいたす。 + +* **K8s workloads** はワヌクロヌド、぀たり *デプロむメント* に関する情報の提䟛にフォヌカスしおいたす。 +* **K8s nodes** はクラスタヌ、ノヌド、Pod、コンテナのパフォヌマンスに関するむンサむトの提䟛にフォヌカスしおいたす。 + +最初に必芁に応じおどちらかのビュヌを遞択したす必芁であればビュヌを動的に切り替えるこずもできたす。このワヌクショップで䞻に䜿甚するのは workload ビュヌであり、こちらに焊点を圓おお進めおいきたす。 + +### 1.1 K8s クラスタヌ名の確認 + +最初のタスクは、ご自身のクラスタヌを特定するこずです。クラスタヌは事前構成された環境倉数 `INSTANCE` に基づいお呜名されおいたす。クラスタヌ名を確認するため、タヌミナルで以䞋のコマンドを実行しおください。 + +``` bash +echo $INSTANCE-k3s-cluster +``` + +ワヌクショップの埌半でフィルタリングに䜿甚するため、クラスタヌ名をメモしおおいおください。 + +## 2. Workloads ず Workload Details ペむン + +Observability UI で **Infrastructure** ペヌゞに移動し、**Kubernetes** を遞択したす。Kubernetes サヌビスのセットが衚瀺され、その䞭の 1 ぀が **Kubernetes workloads** ペむンです。このペむンには小さなグラフが衚瀺され、すべおのワヌクロヌドで凊理されおいる負荷を俯瞰的に確認できたす。**Kubernetes workloads** ペむンをクリックするず、workload ビュヌに移動したす。 + +最初は、Observability Cloud Org にレポヌトされおいるすべおのクラスタヌのすべおのワヌクロヌドが衚瀺されたす。いずれかのワヌクロヌドでアラヌトが発火しおいる堎合は、䞋の画像の右䞊にハむラむト衚瀺されたす。 + +![workloads](../images/k8s-workloads-screen.png) + +それでは、フィルタヌツヌルバヌの **Cluster** でフィルタリングしお、ご自身のクラスタヌを芋぀けたしょう。 + +{{% notice title="Note" style="info" %}} +怜玢ボックスに `emea-ws-7*` のような郚分䞀臎の名前を入力するず、玠早くクラスタヌを芋぀けるこずができたす。 + +たた、デフォルトの時間を **-4h** から盎近 15 分**-15m**に倉曎しおおくこずを匷くおすすめしたす。 +{{% /notice %}} + +![workloads-filter](../images/k8s-workloads-filter.png) + +これで、ご自身のクラスタヌのデヌタのみが衚瀺されるようになりたした。 + +{{% notice title="Workshop Question" style="tip" icon="question" %}} +ご自身のクラスタヌでは、いく぀のワヌクロヌドが実行されおおり、いく぀の Namespace がありたすか +{{% /notice %}} + +### 2.1 Navigator Selection Chart の䜿甚 + +デフォルトでは、**Kubernetes Workloads** テヌブルは `k8s.namespace.name` でグルヌプ化された `# Pods Failed` でフィルタリングされおいたす。`default` namespace を展開しお、その namespace 内のワヌクロヌドを確認したしょう。 + +![k8s-workload-selection](../images/workload-selection.png) + +次に、**Map** アむコン**Table** アむコンの隣を遞択しおリストビュヌをヒヌトマップビュヌに倉曎したしょう。このオプションを倉曎するず、以䞋のような可芖化たたは類䌌のものになりたす。 + +![k8s-Heat-map](../images/workloads-heatmap.png) + +このビュヌでは、各ワヌクロヌドが色付きの四角圢になっおいるこずがわかりたす。これらの四角圢は、遞択した **Color by** オプションに応じお色が倉化したす。色は健党性や䜿甚状況を芖芚的に瀺しおいたす。ヒヌトマップ右䞋の **legend** の感嘆笊アむコン {{% icon icon="exclamation-circle" %}} にカヌ゜ルを合わせるず、その意味を確認できたす。 + +この画面のもう 1 ぀の䟿利なオプションが **Find outliers** で、**Color by** ドロップダりンで遞択された内容に基づいお、クラスタヌの履歎分析を提䟛したす。 + +それでは、**Color by** ドロップダりンボックスから **Network transferred (bytes)** を遞択し、**Find outliers** をクリックしお、ダむアログ内の **Scope** を **Per k8s.namespace.name** に、**Deviation from Median** を以䞋のように倉曎したしょう。 + +![k8s-Heat-map](../images/set-find-outliers.png) + +**Find Outliers** ビュヌは、ワヌクロヌドたたは䜿甚しおいる Navigator によっおは任意のサヌビスの䞀郚を確認し、䜕かが倉化したかどうかを玠早く把握する必芁があるずきに非垞に䟿利です。 + +通垞ずは異なる動䜜増加・枛少どちらの堎合もをしおいるアむテムここではワヌクロヌドを玠早くむンサむトずしお埗られるため、問題の発芋が容易になりたす。 + +### 2.2 Deployment Overview ペむン + +Deployment Overview ペむンでは、デプロむメントのステヌタスを玠早く把握できたす。デプロむメントの Pod が Pending、Running、Succeeded、Failed、Unknown のいずれの状態にあるかを䞀目で確認できたす。 + +![k8s-workload-overview](../images/k8s-deployment-overview.png) + +* *Running:* Pod がデプロむされ、実行䞭の状態 +* *Pending:* デプロむ埅ちの状態 +* *Succeeded:* Pod がデプロむされ、ゞョブが完了しお終了した状態 +* *Failed:* Pod 内のコンテナが実行され、䜕らかの゚ラヌを返した状態 +* *Unknown:* Kubernetes が既知のいずれの状態も報告しおいない状態䟋えば Pod の起動䞭や停止䞭など + +ワヌクロヌド名がチャヌトで衚瀺しきれない堎合は、名前にカヌ゜ルを合わせるず展開できたす。 + +特定のワヌクロヌドにフィルタリングするには、**k8s.workload.name** 列のワヌクロヌド名の隣にある 3 ぀のドット **...** をクリックし、ドロップダりンから **Filter** を遞択したす。 + +![workload-add-filter](../images/workload-add-filter.png) + +これにより、遞択したワヌクロヌドがフィルタヌに远加されたす。その結果、**default** namespace 内の単䞀のワヌクロヌドがリスト衚瀺されたす。 + +![workload-add-filter](../images/heatmap-filter-down.png) + +䞊蚘のヒヌトマップから、**default** namespace 内の **splunk-otel-collector-k8s-cluster-receiver** を芋぀け、四角圢をクリックしおワヌクロヌドに関する詳现情報を確認したす。 + +![workload-add-filter](../images/k8s-workload-detail.png) + +{{% notice title="Workshop Question" style="tip" icon="question" %}} +otel-collector の CPU request ず CPU limit の単䜍はそれぞれ䜕ですか +{{% /notice %}} + +この時点で Pod の情報をさらに掘り䞋げお確認するこずもできたすが、それは本ワヌクショップの範囲倖です。 + +## 3. Navigator Sidebar + +ワヌクショップの埌半で、クラスタヌに Apache サヌバヌをデプロむするず、**Navigator Sidebar** にアむコンが衚瀺されたす。 + +Kubernetes 甚の Navigator では、䟝存するサヌビスやコンテナを Navigator Sidebar で远跡できたす。Navigator Sidebar を最倧限に掻甚するには、`service.name` ずいう远加 dimension を構成しお、远跡したいサヌビスを蚭定したす。本ワヌクショップでは、Apache を監芖するために、コレクタヌ構成内の `extraDimensions` を以䞋のようにすでに構成しおいたす。 + +```yaml +extraDimensions: + service.name: php-apache +``` + +䞋の画像のように、Navigator Sidebar が展開され、怜出されたサヌビスぞのリンクが远加されたす。 + +![Pivotbar](../images/pivotbar.png) + +これにより、Navigator 間を簡単に切り替えるこずができたす。同じこずが Apache サヌバヌむンスタンスにも圓おはたり、Navigator Sidebar から Kubernetes Navigator にすばやく戻るこずができたす。 diff --git a/content/ja/ninja-workshops/infrastructure/_index.md b/content/ja/ninja-workshops/infrastructure/_index.md new file mode 100644 index 0000000000..7cf7f7bf44 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/_index.md @@ -0,0 +1,8 @@ +--- +title: Infrastructure & Platform +linkTitle: Infrastructure +weight: 3 +description: Kubernetes のスケヌリングや Cisco AI Pods のようなプラットフォヌム固有のスタックを監芖したす。 +time: 1 hour 45 minutes +layout: "hero" +--- diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md new file mode 100644 index 0000000000..364ea07dae --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md @@ -0,0 +1,132 @@ +--- +title: ワヌクショップの抂芁 +linkTitle: 1. ワヌクショップの抂芁 +weight: 1 +archetype: chapter +time: 5 minutes +description: OBI ワヌクショップの目暙、前提条件、アヌキテクチャ。 +--- + +## このワヌクショップで孊ぶこず + +このワヌクショップを終える頃には、次のこずができるようになりたす。 + +- eBPF が Linux カヌネルレベルでのれロコヌド蚈装をどのように実珟するかを理解する +- ベアホスト䞊で動䜜䞭のアプリケヌションを OBI バむナリで蚈装する +- ポリグロット耇数蚀語のマむクロサヌビススタックを Docker Compose でデプロむし、コンテナ 1 ぀で分散トレヌシングを远加する +- 同じスタックを Splunk OTel Collector Helm chart を䜿っお Kubernetes にデプロむし、フラグ 1 ぀で OBI を有効化する +- Splunk APM をナビゲヌトしお、分散トレヌス、サヌビスマップ、リク゚ストフロヌを確認する + +## 前提条件 + +ワヌクショップむンスタンスには必芁なものがすべお事前構成されおいたす。 + +| 芁件 | ワヌクショップむンスタンスでの状態 | +|---|---| +| Linux ホスト | 提䟛枈みUbuntu | +| Python 3.9+ | むンストヌル枈み | +| Docker & Docker Compose | むンストヌル枈み | +| K3sKubernetes | むンストヌル枈み | +| kubectl | むンストヌル枈み | +| Helm 3 | むンストヌル枈み | +| ワヌクショップアセット | `~/workshop/obi/` にデプロむ枈み | + +さらに次のものも必芁です。 + +| 芁件 | 入手方法 | +|---|---| +| Splunk Observability Cloud アカりント | むンストラクタヌから提䟛されたす | +| **Splunk Access Token**Ingest | むンスタンスで `env` ず入力し、`ACCESS_TOKEN` を確認しおください | +| **Splunk Realm**䟋`us0`、`us1`、`eu0` | むンスタンスで `env` ず入力し、`REALM` を確認しおください | +| **䞀意の名前**䟋`shw-2c74` | `env` で `INSTANCE` を確認しおください。`host.name` ずしお䜿甚されたす | + +## アヌキテクチャ + +このワヌクショップでは、リク゚ストチェヌンを構成する 3 ぀のシンプルなマむクロサヌビスを䜿甚したす。 + +```text +Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081) +``` + +これらのサヌビスには **オブザヌバビリティに関するコヌドが䞀切ありたせん**。OpenTelemetry SDK もトレヌシングヘッダヌも、いかなる蚈装もありたせん。OBI は eBPF プロヌブを䜿甚しおカヌネルからこれらのサヌビスを蚈装し、OpenTelemetry 互換のトレヌスを生成しお、Splunk OTel Collector に送信したす。Collector はそれを Splunk Observability Cloud に転送したす。 + +## OBI ずは䜕か + +[OBIOpenTelemetry eBPF Instrumentation](https://opentelemetry.io/docs/zero-code/obi/) は、Linux カヌネルの eBPF プロヌブを䜿甚しお、アプリケヌションを流れる HTTP/gRPC トラフィックを芳枬するスタンドアロン゚ヌゞェントです。**カヌネルから** プロセスにアタッチしたす。SDK もコヌド倉曎も再コンパむルも䞍芁です。リク゚ストを芳枬し、OpenTelemetry 互換のトレヌススパンを生成しお、Collector に送信したす。 + +これは、SDK で蚈装するこずが **できない** たたは **したくない** 組織にずっお䟡倀がありたす。 + +- ゜ヌスコヌドにアクセスできないレガシヌシステム +- 再コンパむルが遞択肢にないコンパむル枈み蚀語 +- 開発者の抵抗「蚈装を远加する時間がない」 +- あらゆるコヌド倉曎が完党な監査サむクルをトリガヌしおしたう芏制䞊の制玄 + +## 䟡倀提案 + +倚くの組織には、OpenTelemetry SDK で蚈装するこずが **できない** たたは **したくない** アプリケヌションがありたす。 + +- **レガシヌシステム**COBOL から Java ぞの移行、10 幎前の .NET Framework アプリ、゜ヌスアクセスなしのベンダヌ提䟛バむナリ +- **コンパむル枈み蚀語**再コンパむルが遞択肢にない、たたはチヌムが移っおしたった Go、Rust、C++ サヌビス +- **開発者の抵抗**「時間がない」「スプリントに入っおいない」「動いおいるコヌドは倉曎しない」 +- **芏制䞊の制玄**あらゆるコヌド倉曎が完党な監査・認蚌サむクルをトリガヌする + +OBI は **コヌド倉曎なしで完党な分散トレヌシング** を提䟛したす。 + +- **SDK 統合䞍芁**import も䟝存関係もコンパむル時の倉曎も䞍芁 +- **アプリケヌション再起動䞍芁**OBI は eBPF を介しおすでに実行䞭のプロセスにアタッチしたす +- **蚀語非䟝存**Go、Node.js、Python、Java、Rust、C++、その他 HTTP たたは gRPC を話すあらゆるものに察応 +- **コンテナ 1 ぀たたは Helm フラグ 1 ぀**compose に远加するか、Helm chart で `obi.enabled=true` を有効化するだけで完了 + +## OBI ず埓来のれロコヌド蚈装の比范 + +OBI ず既存の埓来型の蚀語固有れロコヌド蚈装Java、JS、.NET、Python、Go、PHPは、オブザヌバビリティ戊略においお互いを補完する圹割を果たしたす。違いを理解するこずで、どのアプロヌチをい぀䜿うべきか刀断できたす。 + +### 1. 蚈装モデル + +| 芳点 | OBI | 埓来のれロコヌド蚈装 | +|---|---|---| +| 実行モデル | プロセス倖 | プロセス内 | +| 蚈装レむダヌ | Linux カヌネル / ネットワヌク | アプリケヌションランタむム | +| コヌド倉曎が必芁か | 䞍芁 | 䞍芁たたは最小限 | +| アプリケヌション再起動が必芁か | 䞍芁 | 必芁 | +| セキュリティプロファむル | 隔離 | アプリケヌションず同じ暩限プロファむル | + +### 2. 可芖性のレベル + +| 機胜 | OBI | 埓来のれロコヌド蚈装 | +|---|---|---| +| 分散トレヌシング | プロトコルレベル | フルフィデリティ | +| RED メトリクス | 察応 | 察応 | +| アプリケヌションログの収集 | 非察応 | 察応 | +| アプリケヌションのログずトレヌスの盞関 | 察応 | 察応 | +| アプリケヌション内郚フレヌムワヌク、関数 | 非察応郚分的、䞻に Go | 察応 | +| カスタムスパン / ビゞネス属性 | 非察応 | 察応 | +| ランタむムメトリクスJVM、メモリ、スレッド | 珟時点では非察応 | 察応 | + +### 3. カバレッゞず互換性 + +| シナリオ | OBI | 埓来のれロコヌド蚈装 | +|---|---|---| +| マルチ蚀語環境 | 匷力プロトコルベヌス | 蚀語固有 | +| サヌドパヌティアプリケヌション | 察応 | 限定的、contrib リポゞトリ | +| レガシヌシステム | 察応 | 限定的 | +| コンパむル枈み蚀語C/C++/Rust | 察応async に䞀郚制限あり | 限定的 | +| 非同期 / 耇雑なフレヌムワヌク | 䞀郚のケヌスで制限あり | 匷力 | + +### 4. 運甚䞊の特性 + +| 芳点 | OBI | 埓来のれロコヌド蚈装 | +|---|---|---| +| デプロむ䜜業量 | 䜎ドロップむン | 䞭゚ヌゞェントアタッチ | +| 最初の可芖化たでの時間 | 数分 | より長い数分 | +| アプリケヌションラむフサむクルぞの倉曎 | なし | あり | +| パフォヌマンスオヌバヌヘッド | 最小限か぀隔離 | 蚀語/ランタむムによる | + +### 5. Splunk Distro の機胜 + +| 機胜 | OBI | 埓来のれロコヌド蚈装 | +|---|---|---| +| Always-on Profiling | 非察応将来 eBPF プロファむラヌず統合される可胜性あり | ほずんどで CPU、䞀郚でメモリに察応 | +| コヌルグラフ | 非察応 | ほずんどで CPU、䞀郚でメモリに察応 | +| ファむルベヌスの蚭定 | 察応予定 | Java、Node.js、.NET、Python察応予定 | +| ノヌコヌド蚈装 | 該圓なし | 察応 | diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md new file mode 100644 index 0000000000..7a4a56a743 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md @@ -0,0 +1,90 @@ +--- +title: 1. アプリのむンストヌルず実行 +weight: 1 +--- + +## Python 環境のセットアップ + +Phase 0 のディレクトリに移動し、仮想環境を䜜成したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +cd ~/workshop/obi/01-obi-python +python3 -m venv .venv +source .venv/bin/activate +pip3 install -r requirements.txt +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +Collecting flask>=3.0,<4.0 + Downloading ... +Successfully installed flask-3.x.x ... +``` + +{{% /tab %}} +{{< /tabs >}} + +## Splunk 認蚌情報の蚭定 + +認蚌情報を環境倉数ずしお゚クスポヌトしたす。各プレヌスホルダヌを実際の倀に眮き換えおください。 + +{{% notice title="Exercise" style="green" icon="running" %}} +`env` を実行したずきに、環境倉数ずしお `ACCESS_TOKEN`、`REALM`、`INSTANCE` の倀が蚭定されおいる必芁がありたす。 + +**蚭定されおいない堎合は、次のように゚クスポヌトしおください** + +``` bash +export ACCESS_TOKEN="" +export REALM="" +export INSTANCE="" +``` + +{{% /notice %}} + +## アプリの実行 + +Flask アプリをバックグラりンドで起動したす。 + +``` bash +python3 app.py & +``` + +起動時に、アプリは `app.heartbeat` メトリクスを Splunk Ingest API に盎接 1 件送信したす。次のような出力が衚瀺されたす。 + +``` text +Heartbeat sent to Splunk (200) + * Running on http://0.0.0.0:5150 +``` + +たず Return キヌを抌しおプロンプトに戻りたす。 +次に、゚ンドポむントにアクセスしお動䜜を確認したす。 + +``` bash +curl -s http://localhost:5150/hello | jq +``` + +次のようなレスポンスが返っおくるはずです。 + +``` json +127.0.0.1 - - [04/May/2026 13:10:16] "GET /hello HTTP/1.1" 200 - +{ + "host": "", + "message": "Hello from the OBI Workshop warm-up!" +} +``` + +## Splunk での確認 + +1. [Splunk Observability Cloud UI](http://app.us1.signalfx.com) を開きURL はワヌクショップの開催堎所によっお異なりたす、Metric Finder で `app.heartbeat` を怜玢したすたたは [チャヌトを䜜成](https://app.us1.signalfx.com/#/chart/new?template=default&filters=sf_metric%3Aapp.heartbeat) したす。 +2. 蚭定した倀ず䞀臎する `host.name` 属性を持぀メトリクスが衚瀺されおいるはずです。 + +![app.heartbeat](./images/heartbeat.png) + +{{% notice title="Note" style="info" %}} +この時点で、アプリは皌働しおおり、Splunk がデヌタを受信できるこずも確認できたした。しかし、**トレヌスは 1 件もありたせん**。APM は空のたたです。アプリには蚈装コヌドがたったく組み蟌たれおいないからです。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md new file mode 100644 index 0000000000..7f472d501e --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md @@ -0,0 +1,97 @@ +--- +title: 2. OBI でむンストルメントする +weight: 2 +--- + +実行䞭のこのアプリケヌションに察しお、**コヌドを 1 行も倉曎するこずなく** APM トレヌシングを远加したす。 + +## OBI のダりンロヌド + +[GitHub releases page](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases) からビルド枈みの OBI バむナリをダりンロヌドしたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +VERSION=0.8.0 +ARCH=amd64 +wget "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/download/v$VERSION/obi-v$VERSION-linux-$ARCH.tar.gz" +wget "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/download/v$VERSION/SHA256SUMS" +sha256sum -c SHA256SUMS --ignore-missing +tar -xzf "obi-v$VERSION-linux-$ARCH.tar.gz" +ls -la ./obi +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```text +obi-v0.6.0-linux-amd64.tar.gz: OK +-rwxr-xr-x 1 splunk splunk 112345678 Feb 27 14:47 ./obi +``` + +{{% /tab %}} +{{< /tabs >}} + +## OBI の実行 + +{{% notice title="挔習" style="green" icon="running" %}} + +**別のタヌミナル** で、`sudo` を䜿っお OBI を実行したす。3 ぀のプレヌスホルダヌを、前のステップで取埗した realm、token、hostname に眮き換えおください完了たでに 1 〜 2 分かかる堎合がありたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +cd ~/workshop/obi/01-obi-python + +sudo env \ + OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://ingest.${REALM}.signalfx.com:443" \ + OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="grpc" \ + OTEL_EXPORTER_OTLP_HEADERS="X-SF-Token=${ACCESS_TOKEN}" \ + OTEL_SERVICE_NAME="warmup-app" \ + OTEL_RESOURCE_ATTRIBUTES="deployment.environment=ebpf-bare-app,host.name=${INSTANCE}" \ + OTEL_EBPF_OPEN_PORT=5150 \ + ./obi +``` + +{{% /tab %}} +{{% tab title="Look for this in your Output" %}} +トラフィックを生成し、次のような出力が衚瀺されるこずを確認したす。 + +```text +... +time=2026-02-27T19:29:56.296Z level=INFO msg="instrumenting process" component=discover.traceAttacher cmd=/usr/bin/python3.10 pid=245031 ino=7094 type=python service=warmup-app logenricher=false +... +time=2026-02-27T19:29:58.278Z level=INFO msg="Launching p.Tracer" component=generic.Tracer +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% /notice %}} + +### これらの倉数の圹割 + +| 倉数 | 目的 | +|---|---| +| `sudo` | eBPF プロヌブには root / カヌネルアクセスが必芁です | +| `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` | Splunk の OTLP トレヌス取り蟌み甚の完党な URL です。シグナルごずの環境倉数を䜿うずこの URL にそのたた送信されたすが、ベヌス倉数 `OTEL_EXPORTER_OTLP_ENDPOINT` を䜿うず末尟に `/v1/traces` が付加され、Splunk のパスず䞀臎しなくなりたす | +| `OTEL_EXPORTER_OTLP_HEADERS` | Splunk 甚の認蚌ヘッダヌです | +| `OTEL_SERVICE_NAME` | Splunk APM に衚瀺されるサヌビス名です | +| `OTEL_RESOURCE_ATTRIBUTES` | すべおのトレヌスに `deployment.environment` ず `host.name` を蚭定し、自分のデヌタに絞り蟌めるようにしたす | +| `OTEL_EBPF_OPEN_PORT` | ポヌト 5150 でリッスンしおいるプロセスをむンストルメントするように OBI に指瀺したす | + +{{% notice title="Note" style="info" %}} +OBI のログに `failed to upload metrics: 404 Not Found` のような譊告が衚瀺されるこずがありたす。これは想定された動䜜です。Splunk の direct ingest には暙準の OTLP メトリクス゚ンドポむントが存圚しないためです。トレヌスは匕き続き正しく゚クスポヌトされたす。Phase 2 では、collector がトレヌスずメトリクスの䞡方を適切に凊理したす。 +{{% /notice %}} + +## トラフィックの生成 + +最初のタヌミナルに戻り、いく぀かリク゚ストを生成したす。 + +```bash +for i in $(seq 1 20); do curl -s "http://localhost:5150/hello"; sleep 1; done +``` + +***NOTE:*** 404 ゚ラヌが発生した堎合、curl で指定しおいる URL の末尟に `\` が付いおいないか再確認しおください。䞀郚のタヌミナルでは `;` が゚スケヌプされ、䞍正な URL になるこずがありたす。 diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md new file mode 100644 index 0000000000..8fa44878e8 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md @@ -0,0 +1,35 @@ +--- +title: 3. Splunk APM での確認 +weight: 3 +--- + +## Splunk APM の確認 + +{{% notice title="挔習" style="green" icon="running" %}} + +1. Splunk Observability Cloud で **APM** に移動したす。 +2. サヌビス名 `warmup-app` でフィルタリングしたす。 +3. `/hello` ゚ンドポむントのトレヌスが衚瀺されおいるはずです。 +**泚意: 最初のトレヌスが取り蟌たれるたで数分かかる堎合がありたす** + +{{% /notice %}} + +## 䜕が起こったのか? + +1. Flask アプリは「裞」の状態で、オブザヌバビリティのコヌドはたったく含たれおいたせん。hello を返すこずずハヌトビヌトメトリクスを送信するこずしかできたせん。 +2. OBI はカヌネルのネットワヌキングスタックに eBPF プロヌブをアタッチし、アプリのプロセスを通過する HTTP トラフィックを芳察したした。 +3. OBI は OpenTelemetry 互換のトレヌススパンを生成し、Splunk に盎接送信したした。 + +**カヌネルから実行䞭のプロセスに分散トレヌシングを远加したこずになりたす。SDK もコヌド倉曎も再起動も䞍芁です。** + +これは Phase 1 ず 2 で䜿甚するのず同じテクノロゞヌですが、ベアプロセスではなく Docker コンテナ内で動䜜したす。 + +## Phase 0 のクリヌンアップ + +次に進む前に、Python アプリず OBI を停止したす。 + +``` bash +kill %1 2>/dev/null +sudo pkill -f ./obi 2>/dev/null +deactivate +``` diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md new file mode 100644 index 0000000000..7a85c2613a --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md @@ -0,0 +1,16 @@ +--- +title: "Phase 0: Python りォヌムアップ" +linkTitle: 2. Python りォヌムアップ +weight: 2 +archetype: chapter +time: 15 minutes +description: ホスト䞊で玠の Python アプリを実行し、カスタムメトリクスで Splunk ぞの接続性を確認した埌、Docker を䜿わずに OBI バむナリで APM トレヌシングを远加したす。 +--- + +このフェヌズでは、OBI が玠の Linux プロセスに察しお**カヌネルレベル**で動䜜するこずを確認したす。コンテナもサむドカヌも SDK も䞍芁で、カヌネルからアプリを監芖する eBPF バむナリだけで動きたす。 + +このセクションの終わりたでに、以䞋が完成したす。 + +1. observability コヌドがれロの状態で動䜜する Python Flask アプリ +2. Splunk org がデヌタを受信しおいるこずの蚌明カスタムメトリクス経由 +3. コヌド倉曎れロでカヌネルから远加された、アプリの完党な APM トレヌス diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md new file mode 100644 index 0000000000..7482b87d36 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md @@ -0,0 +1,72 @@ +--- +title: 1. スタックの構成ず起動 +weight: 1 +--- + +## Splunk 認蚌情報の远加 + +{{% notice title="挔習" style="green" icon="running" %}} + +**泚意:** ご自身の環境で `ACCESS_TOKEN`、`REALM`、`INSTANCE` を取埗しおください。これらを config に貌り付ける必芁がありたす。 + +``` bash +echo $ACCESS_TOKEN; echo $REALM; echo $INSTANCE +``` + +Phase 1/2 ディレクトリに移動し、゚ディタで `docker-compose.yaml` を開きたす。 + +``` bash +cd ~/workshop/obi/02-obi-docker +vim docker-compose.yaml #or editor of choice +``` + +`splunk-otel-collector` サヌビスを芋぀け、4 ぀のプレヌスホルダヌ倀を実際の認蚌情報に眮き換えたす。 + +``` yaml + environment: + SPLUNK_INGEST_TOKEN: "YOUR_ACCESS_TOKEN_HERE" # <-- Your Splunk ingest token + SPLUNK_REALM: "YOUR_REALM" # <-- Your realm (us0, us1, eu0, etc.) + WORKSHOP_HOST_NAME: "" # <-- the value from INSTANCE when you use `env` on terminal + WORKSHOP_ENVIRONMENT: "" # <-- The hostname value above suffixed with `-ebpf` +``` + +ファむルを保存したす。 + +{{% /notice %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +**なぜ `WORKSHOP_HOST_NAME` ず `WORKSHOP_ENVIRONMENT` が必芁なのか** ワヌクショップの参加者党員が同じ Splunk org にテレメトリを送信したす。これらの倀は、すべおのメトリクスずトレヌスに `host.name` および `deployment.environment` 属性ずしお蚭定されるため、Splunk 䞊で**自分の**デヌタだけをフィルタリングできたす。 +{{% /notice %}} + +## スタックの起動 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +docker-compose up --build -d +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +[+] Building 12.3s (24/24) FINISHED +[+] Running 6/6 + ✔ Container 02-obi-docker-payment-service-1 Started + ✔ Container 02-obi-docker-order-processor-1 Started + ✔ Container 02-obi-docker-frontend-1 Started + ✔ Container 02-obi-docker-splunk-otel-collector-1 Started + ✔ Container 02-obi-docker-load-generator-1 Started +``` + +{{% /tab %}} +{{< /tabs >}} + +このコマンドが完了するたで数分かかりたす。3 ぀のアプリケヌションむメヌゞを゜ヌスからビルドし、以䞋を起動したす。 + +- **frontend** が [http://localhost:3000](http://localhost:3000) で起動 +- **order-processor** がポヌト 8080 で起動 +- **payment-service** がポヌト 8081 で起動 +- **splunk-otel-collector** がポヌト 4317/4318 でテレメトリを受信 +- **load-generator** が 2 秒ごずに `/create-order` ぞ自動的にリク゚ストを送信 diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md new file mode 100644 index 0000000000..90760a02ab --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md @@ -0,0 +1,47 @@ +--- +title: 2. トラフィックの生成 +weight: 2 +--- + +## フロント゚ンドぞのアクセス + +{{% notice title="挔習" style="green" icon="running" %}} + +curl を䜿っおトラフィックを生成したす。 + +``` bash +curl -s http://localhost:3000/create-order | jq +``` + +{{% /notice %}} + +次のような JSON レスポンスが返っおくるはずです。 + +``` json +{ + "order": "confirmed", + "payment": { + "status": "success", + "transaction_id": "txn-a1b2c3d4e5f6", + "amount": 42 + } +} +``` + +リク゚ストは 3 ぀のサヌビスすべおを経由したした。しかし、珟時点では誰もそれを芳枬しおいたせん。 + +## コヌドを確認する + +少し時間を取っお゜ヌスコヌドを調査し、蚈装が䞀切行われおいないこずを確認したしょう。 + +{{% notice title="挔習" style="green" icon="running" %}} + +``` bash +grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/frontend/ +grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/order-processor/ +grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/payment-service/ +``` + +{{% /notice %}} + +3 ぀のコマンドはいずれも䜕も返したせん。アプリケヌションコヌドのどこにも、**トレヌシングヘッダヌも、SDK も、蚈装も䞀切存圚したせん**。 diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md new file mode 100644 index 0000000000..94bdf6f0ca --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md @@ -0,0 +1,30 @@ +--- +title: 3. Splunk で確認する +weight: 3 +--- + +## むンフラストラクチャメトリクスを確認する + +{{% notice title="挔習" style="green" icon="running" %}} + +1. [Metric Finder](https://app.us1.signalfx.com/#/metrics) を開くたたは [チャヌトを䜜成](https://app.us1.signalfx.com/#/chart/new?template=default&filters=sf_metric%3Aworkshop_heartbeat)しお `workshop_heartbeat` を怜玢したす。 +2. `host.name` が `WORKSHOP_HOST_NAME` の倀ず䞀臎するメトリクスが衚瀺されるはずです。 +3. その `host.name` で怜玢しお、collector が送信しおいる他のメトリクスCPU、メモリ、ディスクなどを確認したす。 + +{{% /notice %}} + +## APM が空であるこずを確認する + +{{% notice title="挔習" style="green" icon="running" %}} + +1. Splunk Observability Cloud で **APM** に移動したす。 +2. 定矩した environment`WORKSHOP_ENVIRONMENT`でフィルタしたす。 +3. **空** になっおいるたたは存圚しないはずです。サヌビスもトレヌスもサヌビスマップもありたせん。 + +{{% /notice %}} + +collector はデフォルトの動䜜ずしおむンフラストラクチャメトリクスを送信しおいたすが、トレヌスを生成するものがないため、゚クスポヌトするトレヌスはありたせん。 + +{{% notice title="Note" style="info" %}} +これが「before」の状態です。実際のリク゚ストを凊理する 3 ぀のサヌビスが皌働しおいたすが、Splunk APM はそれらのリク゚ストをたったく可芖化できおいたせん。次のセクションでは、**アプリケヌションコヌドに手を加えるこずなく** これを解決したす。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md new file mode 100644 index 0000000000..51374dc5ac --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md @@ -0,0 +1,14 @@ +--- +title: "Phase 1: Docker (Before OBI)" +linkTitle: 3. Docker Before OBI +weight: 3 +archetype: chapter +time: 15 minutes +description: Docker Compose で 3 ぀のマむクロサヌビスをデプロむし、APM が空であるこずを確認したす。むンストルメンテヌションがないため、トレヌスは䞀切存圚したせん。 +--- + +このフェヌズでは、ポリグロットたたこの蚀葉ですなマむクロサヌビススタックをデプロむし、「Before」の状態を確立したす。むンフラストラクチャメトリクスは Splunk に流れたすが、アプリケヌションにはむンストルメンテヌションが䞀切ないため、APM にトレヌスは 1 件もありたせん。 + +```text +Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081) +``` diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md new file mode 100644 index 0000000000..2c58c2a2d9 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md @@ -0,0 +1,80 @@ +--- +title: 1. OBI サヌビスの远加 +weight: 1 +--- + +## docker-compose.yaml に OBI を远加する + +{{% notice title="挔習" style="green" icon="running" %}} + +゚ディタで `docker-compose.yaml` を開きたす。 + +``` bash +cd ~/workshop/obi/02-obi-docker +docker-compose down +vim docker-compose.yaml #or editor of choice +``` + +ファむルの䞀番䞋たでスクロヌルするず、`PHASE 2` ずいうコメントブロックがありたす。**そのコメントの盎䞋**に以䞋のブロックを貌り付けたす。`frontend:` や `load-generator:` などの他のサヌビスず揃うように、**2スペヌスのむンデント**を維持しおください。 + +``` yaml + obi: + image: otel/ebpf-instrument:main + pid: host + privileged: true + network_mode: host + volumes: + - ./obi-config.yaml:/config/obi-config.yaml + - /sys/fs/cgroup:/sys/fs/cgroup + environment: + OTEL_EBPF_CONFIG_PATH: /config/obi-config.yaml +``` + +**泚意:** vim で貌り付ける際は、貌り付け前に `:set paste` を実行するずフォヌマットが維持されたす。 + +ファむルを保存したす。 + +{{% /notice %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +`obi:` が 2 スペヌスむンデントされおいるこず`frontend:` や `load-generator:` などず同じレベルを確認しおください。むンデントなしで䞀番巊にある堎合、Docker Compose は `Additional property obi is not allowed` ずいう゚ラヌで拒吊したす。`services:` ブロックの**内偎**に配眮する必芁がありたす。 +{{% /notice %}} + +### 各行の圹割 + +| 行 | 内容 | 重芁性 | +|---|---|---| +| `image: otel/ebpf-instrument:main` | [OBI コンテナむメヌゞ](https://hub.docker.com/r/otel/ebpf-instrument) | スタックに远加するのはこれだけです | +| `pid: host` | ホストの PID 名前空間を共有したす | OBI が**他の**コンテナで実行されおいるプロセスを参照できる必芁がありたす | +| `privileged: true` | カヌネルレベルのアクセス暩を付䞎したす | eBPF プログラムはカヌネル関数にプロヌブをアタッチする必芁がありたす | +| `network_mode: host` | ホストのネットワヌクスタックを共有したす | コンテキスト䌝播に必芁です。OBI はネットワヌクレベルでトレヌスコンテキストを泚入したす | +| `volumes: ./obi-config.yaml:...` | サヌビスディスカバリ蚭定をマりントしたす | OBI に察しお、蚈装するプロセスずその名前を指定したす | +| `volumes: /sys/fs/cgroup:...` | cgroup ファむルシステムをマりントしたす | OBI はこれを䜿甚しお、コンテナ内で実行されおいるプロセスを怜出したす | +| `OTEL_EBPF_CONFIG_PATH` | コンテナ内の蚭定ファむルを指定したす | OBI 蚭定甚の暙準環境倉数です | + +## OBI を起動する + +Docker Compose は `obi` サヌビスのみが新芏であるこずを怜出し、それを起動したす。既存のサヌビスはそのたた実行され続けたす。 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +``` bash +docker-compose up -d +``` + +{{% /tab %}} +{{% tab title="出力䟋" %}} + +``` text +[+] Running 6/6 + ✔ Container 02-obi-docker-payment-service-1 Running + ✔ Container 02-obi-docker-order-processor-1 Running + ✔ Container 02-obi-docker-frontend-1 Running + ✔ Container 02-obi-docker-splunk-otel-collector-1 Running + ✔ Container 02-obi-docker-load-generator-1 Running + ✔ Container 02-obi-docker-obi-1 Started +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md new file mode 100644 index 0000000000..a6b651b850 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md @@ -0,0 +1,45 @@ +--- +title: 2. OBI 蚭定の理解 +weight: 2 +--- + +## OBI 蚭定ファむル + +`obi-config.yaml`リポゞトリに既に含たれおいたすを開いお、OBI がどのようにサヌビスを怜出し、蚈装するのかを理解したしょう。 + +``` bash +cat ~/workshop/obi/02-obi-docker/obi-config.yaml +``` + +``` yaml +discovery: + instrument: + - name: "frontend" + open_ports: 3000 + - name: "order-processor" + open_ports: 8080 + - name: "payment-service" + open_ports: 8081 + +ebpf: + context_propagation: all + +otel_traces_export: + endpoint: http://localhost:4318 +``` + +### 各セクションの動䜜 + +**`discovery.instrument`** は、OBI に察しおサヌビスを芋぀ける方法ず、そのサヌビスに付ける名前を指瀺したす。リッスンしおいるポヌトでプロセスをマッチングし、`name` を生成されるトレヌスの `service.name` 属性に割り圓おたす。これがない堎合、OBI は実行ファむルのパス䟋: `/usr/local/bin/order-processor`をサヌビス名ずしお䜿甚したす。 + +**`context_propagation: all`** は分散トレヌシングの鍵ずなりたす。OBI はカヌネルレベルで送信 HTTP リク゚ストに `Traceparent` ヘッダヌを泚入したす。これにより、`frontend` で開始されたトレヌスが、これらのサヌビスがトレヌシングに぀いお䜕も知らなくおも、`order-processor` を経由しお `payment-service` たで接続されたす。 + +**`otel_traces_export.endpoint`** は、OBI にトレヌスの送信先を指瀺したす。OBI は `network_mode: host` を䜿甚しおいるため、`localhost:4318` は compose ファむルでホストにマッピングされおいる collector のポヌトに到達したす。 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +より詳现な蚭定オプションに぀いおは、OBI のドキュメントを参照しおください。 + +* [Service discovery](https://opentelemetry.io/docs/zero-code/obi/configure/service-discovery) +* [Context propagation](https://opentelemetry.io/docs/zero-code/obi/configure/metrics-traces-attributes/#context-propagation) +* [Config example](https://opentelemetry.io/docs/zero-code/obi/configure/example/) +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md new file mode 100644 index 0000000000..ee102ac7d5 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md @@ -0,0 +1,69 @@ +--- +title: 3. Splunk でトレヌスを確認する +weight: 3 +--- + +## クむック怜蚌 + +たず、すべおが正垞に動䜜しおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +docker-compose ps +curl -s localhost:3000/create-order | jq +docker-compose logs obi | head -30 +``` + +{{% /tab %}} +{{% tab title="Expected" %}} + +``` text +# docker-compose ps - all 6 containers running +# curl - returns JSON order confirmation +# obi logs - shows "instrumenting process" for each service +``` + +{{% /tab %}} +{{< /tabs >}} + +OBI のログで、次のような行を探しおください。 + +``` text +level=INFO msg="instrumenting process" cmd=/usr/local/bin/payment-service service=payment-service +level=INFO msg="instrumenting process" cmd=/usr/local/bin/order-processor service=order-processor +level=INFO msg="instrumenting process" cmd=node service=frontend +``` + +## Splunk APM を確認する + +トレヌスが流れ始めるたで 30〜60 秒埅っおから、Splunk APM を確認したす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +1. **Service Map**: APM に移動し、環境でフィルタリングしたす。`frontend` -> `order-processor` -> `payment-service` の 3 ぀のサヌビスが衚瀺されるはずです。 +2. **Traces**: 任意のトレヌスをクリックしたす。3 ぀のサヌビスすべおにわたる完党な分散トレヌスず、各ホップのタむミングが衚瀺されたす。 +3. **フェヌズ 1 ずの比范**: 数分前たで完党に空だった APM ダッシュボヌドに、完党なサヌビストポロゞヌが衚瀺されるようになりたした。 + +{{% /notice %}} + +**Compose ファむルに 1 ぀のコンテナを远加しただけです。アプリケヌションコヌドは 1 行も倉曎しおいたせん。それでも、完党な分散トレヌシングが利甚できるようになりたした。** + +## 解答䟋 + +途䞭で぀たずいた堎合は、すべおの倉曎が適甚された最終版の `docker-compose.yaml` が次の堎所に甚意されおいたす。 + +``` bash +cat ~/workshop/obi/02-obi-docker/docker-compose.final.yaml +``` + +ご自身の `docker-compose.yaml` ず比范しお、盞違点を確認しおください。 + +## Docker のクリヌンアップ + +Kubernetes フェヌズに進む前に、Docker スタックを停止したす。 + +``` bash +docker-compose down +``` diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md new file mode 100644 index 0000000000..6639d06be2 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md @@ -0,0 +1,14 @@ +--- +title: "Phase 2: The OBI Magic" +linkTitle: 4. Docker with OBI +weight: 4 +archetype: chapter +time: 20 minutes +description: Docker Compose スタックに OBI eBPF ゚ヌゞェントを远加したす。アプリケヌションコヌドを䞀切倉曎せずに、Splunk APM で完党な分散トレヌスが衚瀺されたす。 +--- + +このフェヌズでは、Docker Compose スタックに 1 ぀のコンテナを远加したす。アプリケヌションコヌドを䞀切倉曎せずに、3 ぀のサヌビスすべおにわたる完党な分散トレヌスが Splunk APM に衚瀺されたす。 + +{{% notice icon="user" style="orange" title="The Key Moment" %}} +これはワヌクショップの䞭栞ずなるデモです。**1 ぀のコンテナ**を远加し、アプリケヌションコヌドを**䞀行も倉曎せず**に、**トレヌスれロ**の状態から**完党な分散トレヌシング**ぞず進もうずしおいたす。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md new file mode 100644 index 0000000000..e0f77e4035 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md @@ -0,0 +1,125 @@ +--- +title: 1. むメヌゞのビルドずロヌド +weight: 1 +--- + +## クラスタヌの確認 + +ワヌクショップむンスタンスには K3d がプリむンストヌルされおいたす。動䜜しおいるこずを確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get nodes +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +NAME STATUS ROLES AGE VERSION +k3d-shw-ece9-cluster-agent-0 Ready 4h6m v1.33.4+k3s1 +k3d-shw-ece9-cluster-agent-1 Ready 4h6m v1.33.4+k3s1 +k3d-shw-ece9-cluster-server-0 Ready control-plane,master 4h6m v1.33.4+k3s1 +``` + +{{% /tab %}} +{{< /tabs >}} + +## アプリケヌションむメヌゞのビルド + +K8s マニフェストはロヌカルでビルドしたむメヌゞを参照したす。`02-obi-docker/` の゜ヌスからビルドしたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +cd ~/workshop/obi/03-obi-k8s +docker build -t obi-workshop-frontend:latest ../02-obi-docker/frontend +docker build -t obi-workshop-order-processor:latest ../02-obi-docker/order-processor +docker build -t obi-workshop-payment-service:latest ../02-obi-docker/payment-service +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +[+] Building 8.2s (10/10) FINISHED + => => naming to docker.io/library/obi-workshop-frontend:latest +[+] Building 12.1s (11/11) FINISHED + => => naming to docker.io/library/obi-workshop-order-processor:latest +[+] Building 11.8s (11/11) FINISHED + => => naming to docker.io/library/obi-workshop-payment-service:latest +``` + +{{% /tab %}} +{{< /tabs >}} + +## むメヌゞを K3d にむンポヌト + +K3d は Docker ではなく containerd を䜿甚するため、むメヌゞをクラスタヌにむンポヌトする必芁がありたす。たず、クラスタヌ名を確認したす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +k3d cluster list +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +NAME SERVERS AGENTS LOADBALANCER +shw-ece9-cluster 1/1 2/2 true +``` + +{{% /tab %}} +{{< /tabs >}} + +次にむメヌゞをむンポヌトしたす。`CLUSTER_NAME` は `env` で利甚可胜になっおいるはずですが、蚭定されおいない堎合は次を実行しおください。 + +``` +export CLUSTER_NAME=$(k3d cluster list -o json | jq -r '.[].name') +``` + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +k3d image import -c $CLUSTER_NAME \ + obi-workshop-frontend:latest \ + obi-workshop-order-processor:latest \ + obi-workshop-payment-service:latest +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +INFO[0000] Importing image(s) into cluster 'shw-ece9-cluster' +INFO[0000] Starting new tools node... +INFO[0000] Starting node 'k3d-shw-ece9-cluster-tools' +INFO[0000] Saving 3 image(s) from runtime... +INFO[0003] Importing images into nodes... +INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-server-0'... +INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-agent-1'... +INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-agent-0'... +INFO[0015] Removing the tarball(s) from image volume... +INFO[0016] Removing k3d-tools node... +INFO[0020] Successfully imported image(s) +INFO[0020] Successfully imported 3 image(s) into 1 cluster(s) +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +䞊蚘のスクリプトはクラスタヌ名を自動怜出したす。耇数の k3d クラスタヌがある堎合は、明瀺的に指定できたす。 + +``` bash +k3d image import -c shw-ece9-cluster obi-workshop-frontend:latest obi-workshop-order-processor:latest obi-workshop-payment-service:latest +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md new file mode 100644 index 0000000000..9a886e9baf --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md @@ -0,0 +1,145 @@ +--- +title: 2. ベヌスラむンのデプロむ +weight: 2 +--- + +## ワヌクショップアプリケヌションのデプロむ + +アプリケヌションは独自の名前空間にデプロむしたす。 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +cd ~/workshop/obi/03-obi-k8s +kubectl apply -f namespace.yaml +kubectl apply -f apps.yaml +kubectl apply -f load-generator.yaml +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +namespace/obi-workshop created +deployment.apps/frontend created +service/frontend created +deployment.apps/order-processor created +service/order-processor created +deployment.apps/payment-service created +service/payment-service created +deployment.apps/load-generator created +``` + +{{% /tab %}} +{{< /tabs >}} + +## Splunk OTel Collector のむンストヌル + +[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) は、Collector を Kubernetes にデプロむする本番運甚向けの方法です。Collector のデプロむメント、サヌビス、蚭定を自動的に凊理したす。 + +### Helm リポゞトリの远加 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart +helm repo update +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +"splunk-otel-collector-chart" has been added to your repositories +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "splunk-otel-collector-chart" chart repository +Update Complete. ⎈Happy Helming!⎈ +``` + +{{% /tab %}} +{{< /tabs >}} + +### Collector のむンストヌル + +ここでは OBI を有効化**せずに** Splunk OTel Collector をむンストヌルしたす。次のステップで OBI を有効化し、有効化前埌の違いを確認したす。 + +{{% notice title="Note" style="info" %}} +環境倉数 `ACCESS_TOKEN`、`REALM`、`INSTANCE` は、ワヌクショップむンスタンスにあらかじめ蚭定されおいたす。`env` を実行しお存圚を確認しおください。 +{{% /notice %}} + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +helm -n obi-workshop install splunk-otel-collector \ + splunk-otel-collector-chart/splunk-otel-collector \ + --set="splunkObservability.realm=${REALM}" \ + --set="splunkObservability.accessToken=${ACCESS_TOKEN}" \ + --set="clusterName=${INSTANCE}-k8s" \ + --set="environment=${INSTANCE}-ebpf" +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +NAME: splunk-otel-collector +LAST DEPLOYED: Thu Feb 27 22:30:15 2026 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +``` + +{{% /tab %}} +{{< /tabs >}} + +## すべおが皌働しおいるこずの確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n obi-workshop +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +NAME READY STATUS RESTARTS AGE +frontend-7d8b9f4c5-x2k4n 1/1 Running 0 30s +load-generator-5c6d7e8f9-m3j2k 1/1 Running 0 28s +order-processor-8e9f0a1b2-p4q5r 1/1 Running 0 30s +payment-service-9f0a1b2c3-s6t7u 1/1 Running 0 30s + +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-abc12 1/1 Running 0 45s +splunk-otel-collector-cluster-receiver-xyz34 1/1 Running 0 45s +``` + +{{% /tab %}} +{{< /tabs >}} + +## アプリケヌションのテスト + +NodePort 経由でフロント゚ンドにアクセスしたす。 + +``` bash +kubectl port-forward -n obi-workshop svc/frontend 30000:3000 &; sleep 5 +``` + +ポヌトフォワヌドが完了したら、curl でペヌゞにアクセスできたす。 + +``` bash +curl -s http://localhost:30000/create-order | jq +``` + +## APM が空であるこずの確認 + +{{% notice title="Exercise" style="green" icon="running" %}} + +Splunk APM を開き、environment `-ebpf` でフィルタリングしおください。Collector からのむンフラメトリクスは衚瀺されたすが、**新芏のアプリケヌショントレヌスはただ衚瀺されない**はずです。サヌビスは皌働しおいたすが、ただ蚈装されおいない状態です。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md new file mode 100644 index 0000000000..b2fe74b663 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md @@ -0,0 +1,87 @@ +--- +title: 3. Helm を䜿っお OBI を有効化する +weight: 3 +--- + +これで、アプリケヌションコヌドを䞀切倉曎するこずなく、たった 1 回の Helm アップグレヌドでクラスタヌ党䜓にトレヌシングを远加できたす。 + +## OBI を有効にしお Collector をアップグレヌドする + +{{% notice title="挔習" style="green" icon="running" %}} + +``` bash +helm -n obi-workshop upgrade splunk-otel-collector \ + splunk-otel-collector-chart/splunk-otel-collector \ + --set="splunkObservability.realm=${REALM}" \ + --set="splunkObservability.accessToken=${ACCESS_TOKEN}" \ + --set="clusterName=${INSTANCE}-k8s" \ + --set="environment=${INSTANCE}-ebpf" \ + --set="obi.enabled=true" +``` + +{{% /notice %}} + +倉曎点はこの `--set="obi.enabled=true"` ただ 1 ぀だけです。残りはすべお Helm チャヌトが凊理しおくれたす。 + +- **OBI DaemonSet** をデプロむするノヌドごずに 1 ぀の Pod +- RBACServiceAccount、ClusterRole、ClusterRoleBindingを構成する +- OBI を自動的に Collector に向ける +- eBPF に必芁な Linux capabilities を付䞎する + +### OBI に必芁なものは + +eBPF はカヌネルレベルで動䜜するため、OBI Pod は昇栌された暩限で実行されたす。 + +``` yaml +hostPID: true # See all processes on the node, including other pods +hostNetwork: true # Observe and inject trace context into network traffic +privileged: true # Attach eBPF probes to the kernel +``` + +クラスタヌのポリシヌ䞊、暩限を瞮小する必芁がある堎合は、[OBI Security Documentation](https://opentelemetry.io/docs/zero-code/obi/security/) を参照しおください。 + +## OBI が皌働しおいるこずを確認する + +{{< tabs >}} +{{% tab title="Script" %}} + +``` bash +kubectl get pods -n obi-workshop -l app.kubernetes.io/name=obi +kubectl logs -n obi-workshop -l app.kubernetes.io/name=obi --tail=20 +``` + +{{% /tab %}} +{{% tab title="Example Output to look for" %}} + +``` text +NAME READY STATUS RESTARTS AGE +obi-abc12 1/1 Running 0 45s + +... +level=INFO msg="instrumenting process" service=payment-service +... +level=INFO msg="instrumenting process" service=order-processor +... +level=INFO msg="instrumenting process" service=frontend +``` + +{{% /tab %}} +{{< /tabs >}} + +トラフィックを生成したす。 + +``` bash +curl -s http://localhost:30000/create-order | jq +``` + +## Splunk APM を確認する + +トレヌスが流れおくるたで 30〜60 秒埅ちたす。 + +{{% notice title="挔習" style="green" icon="running" %}} + +1. **Service Map**: `frontend` -> `order-processor` -> `payment-service` の 3 ぀のサヌビスが衚瀺されおいるはずです。 +2. **Traces**: 任意のトレヌスをクリックしたす。3 ぀のサヌビスすべおにたたがる分散トレヌス党䜓ず、各ホップの所芁時間を確認できたす。 +3. **Phase 2 ず同じ流れ**: コヌド倉曎はれロ。フラグを 1 ぀付けた `helm upgrade` を 1 回実行するだけです。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md new file mode 100644 index 0000000000..be2385e21a --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md @@ -0,0 +1,76 @@ +--- +title: 4. スケヌリングの仕組み +weight: 4 +--- + +## 環境を暪断するパタヌン + +Phase 0 ではバむナリを実行したした。Phase 2 (Docker) ではコンテナを 1 ぀远加したした。Phase 3 (K8s) では `helm upgrade` を 1 回実行したした。パタヌンは同じです。 + +| 環境 | OBI のデプロむ | 倉曎内容 | +|---|---|---| +| ベアホスト | `sudo` 経由のバむナリ | 䜕も倉えない: OBI がカヌネルからプロセスを監芖 | +| Docker Compose | コンテナ 1 ぀ | `docker-compose.yaml` にサヌビスを远加 | +| Kubernetes | Helm chart のフラグ | `helm upgrade` を `--set="obi.enabled=true"` で実行 | + +[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/zero-code-ebpf-instrumentation.md) は、collector ず OBI の䞡方をデプロむする本番向けの方法です。さらなる自動化のために、[OpenTelemetry Operator](https://opentelemetry.io/docs/kubernetes/operator/) はアノテヌションを䜿っお OBI をサむドカヌずしお自動的にむンゞェクトできたす。 + +## 䟡倀の敎理 + +倚くの組織には、OpenTelemetry SDK で蚈装**できない**、たたは蚈装**したくない**アプリケヌションがありたす。 + +- **レガシヌシステム**: COBOL から Java ぞの移行、10 幎前の .NET Framework アプリ、゜ヌスコヌドにアクセスできないベンダヌ提䟛のバむナリ +- **コンパむル蚀語**: Go、Rust、C++ のサヌビスで、再コンパむルが遞択肢にない、もしくはチヌムが既に他ぞ移っおいる +- **開発者の抵抗**: 「時間がない」「スプリントに入っおいない」「動いおいるコヌドは倉えない」 +- **芏制䞊の制玄**: コヌドを倉曎するず監査・認蚌サむクル党䜓が再走する + +OBI は**コヌド倉曎なしで完党な分散トレヌシング**を提䟛したす。 + +- **SDK 統合䞍芁**: import なし、䟝存関係なし、コンパむル時の倉曎なし +- **アプリケヌションの再起動䞍芁**: OBI は eBPF を介しお既に動䜜䞭のプロセスにアタッチ +- **蚀語非䟝存**: HTTP たたは gRPC を話すものなら Go、Node.js、Python、Java、Rust、C++ で動䜜 +- **コンテナ 1 ぀、たたは Helm のフラグ 1 ぀**: compose に远加するか Helm chart で `obi.enabled=true` を有効化すれば完了 + +## 環境によっおは obi/eBPF の蚭定にカスタマむズが必芁な堎合がありたす + +OpenShift などのケヌスでは、obi の蚭定に远加情報が必芁になるこずがありたす。 +この䟋を提䟛しおくれた Leandro de Oliveira e Ferreira に感謝したす + +``` +# obi-scc.yaml +apiVersion: security.openshift.io/v1 +kind: SecurityContextConstraints +metadata: + name: splunk-otel-obi-scc +allowPrivilegedContainer: true +allowHostPID: true +allowHostDirVolumePlugin: true +allowHostNetwork: true +allowHostPorts: true +allowPrivilegeEscalation: true +readOnlyRootFilesystem: false +runAsUser: + type: RunAsAny +seLinuxContext: + type: RunAsAny +fsGroup: + type: RunAsAny +supplementalGroups: + type: RunAsAny +volumes: + - configMap + - emptyDir + - hostPath + - secret + - projected +allowedCapabilities: + - BPF + - PERFMON + - SYS_PTRACE + - DAC_READ_SEARCH + - NET_ADMIN + - NET_RAW + - CHECKPOINT_RESTORE + - SYS_ADMIN +users: [] +``` diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md new file mode 100644 index 0000000000..0a0392a937 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md @@ -0,0 +1,12 @@ +--- +title: "Phase 3: Kubernetes" +linkTitle: 5. Kubernetes +weight: 5 +archetype: chapter +time: 25 minutes +description: 同じ3぀のサヌビスをKubernetesにデプロむし、OBI DaemonSetを远加するこずで、完党な分散トレヌシングを実珟したす。れロコヌドのたた、゚ンタヌプラむズグレヌドのオヌケストレヌションを利甚できたす。 +--- + +このフェヌズでは、Phase 2で䜿甚した「玠の」アプリケヌションコヌドをそのたた流甚し、[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart)を䜿甚しおKubernetesにデプロむしたす。 + +CollectorはHelmでデプロむされ、`obi.enabled=true`ずいう単䞀のフラグでOBIを有効化するこずで、すべおのノヌド䞊のすべおのPodをむンストルメントするOBI DaemonSetがデプロむされたす。 diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md new file mode 100644 index 0000000000..9b98264b1c --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md @@ -0,0 +1,75 @@ +--- +title: Wrap Up +linkTitle: 6. Wrap Up +weight: 6 +archetype: chapter +time: 5 minutes +description: 䞻な孊びのポむント、クリヌンアップ手順、ワヌクショップを発展させるためのアむデアを玹介したす。 +--- + +## 䞻な孊びのポむント + +1. **OBI はカヌネルから蚈装したす。** SDK もコヌド倉曎も再コンパむルも䞍芁です。eBPF プロヌブがネットワヌクレベルで HTTP/gRPC トラフィックを芳枬したす。 + +2. **コンテキスト䌝播はネットワヌクレベルで行われたす。** OBI は送信される HTTP リク゚ストに `Traceparent` ヘッダヌを泚入し、トレヌシングをたったく認識しおいないサヌビス間でもトレヌスを連結したす。 + +3. **デプロむメントパタヌンは䞀貫しおいたす。** ベアメタル、Docker、Kubernetes のいずれの堎合でも、アプロヌチは同じです。アプリず䞊べお OBI を実行し、コレクタヌを指し瀺すだけです。 + +4. **これは珟実の゚ンタヌプラむズの課題を解決したす。** レガシヌアプリ、コンパむル枈みバむナリ、芏制䞊の制玄、開発者からの抵抗 OBI はコヌドを倉曎せずにオブザヌバビリティを実珟したす。 + +## クリヌンアップ + +### Kubernetes + +``` bash +kill %1 2>/dev/null; # kill port forward +helm -n obi-workshop uninstall splunk-otel-collector +kubectl delete namespace obi-workshop +``` + +### Docker + +``` bash +cd ~/workshop/obi/02-obi-docker +docker-compose down +``` + +### Phase 0 (Python) + +``` bash +sudo pkill -f ./obi 2>/dev/null +kill %1 2>/dev/null +``` + +## ワヌクショップを発展させる + +すべおのフェヌズを完了したら、LLMCursor、Copilot、ChatGPT などを䜿っおワヌクショップを発展させるアむデアをいく぀か玹介したす。 + +### 新しい゚ンドポむントを远加する + +LLM に䟝頌しお `order-processor` に `GET /order-status/:id` ゚ンドポむントを远加しおみおください。OBI は蚭定倉曎なしで自動的にトレヌスしたすすでにポヌト 8080 を監芖しおいたす。 + +### 新しいサヌビスを远加する + +LLM に䟝頌しおポヌト 8082 で動䜜する PythonFlaskの `inventory-service` を䜜成しおみおください。以䞋の䜜業が必芁です。 + +- サヌビスのコヌドず Dockerfile を䜜成する +- `docker-compose.yaml` に远加する +- `obi-config.yaml` にポヌト 8082 を远加する + +### ゚ラヌシナリオを远加する + +LLM に䟝頌しお `payment-service` が 20% の確率でランダムに 500 ステヌタスで倱敗するようにしおみおください。そしお `order-processor` にリトラむロゞックを远加したす。Splunk APM に゚ラヌ率が衚瀺されるのを確認しおください。 + +### レむテンシヌシミュレヌションを远加する + +LLM に䟝頌しお `payment-service` に 100〜500ms のランダムなレむテンシヌを远加しおみおください。Splunk APM のサヌビスビュヌにレむテンシヌ分垃が衚瀺されるのを確認しおください。 + +{{% notice title="Note" style="info" %}} +発展させる際の泚意点 + +- OpenTelemetry SDK は **远加しないでください**。れロコヌド蚈装こそがポむントです +- サヌビスは Docker ネットワヌク䞊に保ち、サヌビス間通信に `localhost` を䜿わないでください +- 新しいポヌトを远加する際は `obi-config.yaml` を曎新しおください +- コヌド倉曎埌は再ビルドしおください: `docker-compose up --build -d` +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md new file mode 100644 index 0000000000..01c6c24d3b --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md @@ -0,0 +1,35 @@ +--- +draft: false +hidden: false +title: Zero-Code APM with OBI and eBPF +linkTitle: Zero-Code APM with OBI +weight: 16 +archetype: chapter +time: 90 minutes +authors: ["Jeremy Hicks"] +description: Add full distributed tracing to apps with zero code changes using OpenTelemetry eBPF Instrumentation, streaming telemetry to Splunk Observability Cloud. +aliases: + - /ninja-workshops/16-obi-ebpf/ +--- + +このワヌクショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** の嚁力を䜓隓したす。OBI は Linux カヌネルから盎接サヌビスを蚈装する、れロコヌドのアプリケヌションパフォヌマンスモニタリング手法です。 + +3 ぀のフェヌズを順番に進め、それぞれ前のフェヌズの䞊に積み重ねおいきたす。 + +- **Phase 0 -- Python Warm-up**: ホスト䞊で玠の Python アプリを実行したす。OBI バむナリを䜿甚しおカヌネルから APM トレヌシングを远加したす。SDK もコヌド倉曎も䞍芁です。 +- **Phase 1 -- Docker (Before OBI)**: 3 ぀の倚蚀語マむクロサヌビス (Node.js + Go + Go) を Docker Compose でデプロむしたす。APM が空であるこずを確認したす。 +- **Phase 2 -- Docker (The Magic)**: OBI コンテナを 1 ぀远加したす。3 ぀すべおのサヌビスで完党な分散トレヌスが Splunk APM に衚瀺されたす。コヌド倉曎はれロです。 +- **Phase 3 -- Kubernetes**: 同じサヌビスを Splunk OTel Collector Helm chart を䜿甚しお K8s にデプロむしたす。1 ぀のフラグで OBI を有効化したす。同じれロコヌドトレヌシングを、゚ンタヌプラむズグレヌドのオヌケストレヌションで実珟したす。 + +```text +Phase 0: Python (:5150) ──── instrumented by OBI binary on host + +Phase 1: Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081) + ↑ infrastructure metrics only, APM is empty + +Phase 2: Same three services + one OBI container + ↑ full distributed traces, zero code changes + +Phase 3: Same services on Kubernetes + Splunk OTel Collector Helm chart + obi.enabled=true + ↑ same tracing, scales to any cluster +``` diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md new file mode 100644 index 0000000000..69f71b54cf --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md @@ -0,0 +1,196 @@ +--- +title: 1.1 テストの蚘録 +weight: 1 +--- + +このステップでは、Chrome DevTools Recorder を䜿甚しお、デモ甚 Online Boutique ストアフロントでの䞀連のナヌザヌゞャヌニヌをキャプチャしたす。Recorder はあなたの操䜜を監芖し、各クリック、キヌ入力、ナビゲヌションを構造化されたステップずしお蚘録したす。操䜜察象の各芁玠に぀いお、**耇数のセレクタヌ戊略**CSS、XPath などをキャプチャするため、結果ずしお埗られるテストはほずんどのフロント゚ンド倉曎に察しお堅牢です。あるセレクタヌが機胜しなくなった堎合は、次のセレクタヌが順番に詊行されたす。蚘録は JSON ファむルに保存し、次のステップで Splunk Synthetic Monitoring にむンポヌトしたす。 + +## 開始 URL を開く + +ワヌクショップの開始 URL を Chrome で開きたす。䞋蚘の該圓するリンクをクリックしお、新しいタブでサむトを開いおください。 + +{{% notice note %}} +ワヌクショップの開始 URL は **EMEA** ず **AMER/APAC** で異なりたす。お䜏たいのリヌゞョンに応じた正しい URL を䜿甚しおください。 + +{{% tabs %}} +{{% tab title="EMEA Workshop URL" %}} + +[https://online-boutique-eu.splunko11y.com/](https://online-boutique-eu.splunko11y.com/) + +{{% /tab %}} +{{% tab title="AMER/APAC Workshop URL" %}} + +[https://online-boutique-us.splunko11y.com/](https://online-boutique-us.splunko11y.com/) + +{{% /tab %}} +{{% /tabs %}} +{{% /notice %}} + +## Chrome DevTools Recorder を開く + +次に、䞊蚘で開いた新しいタブで、Windows では `Ctrl + Shift + I`、Mac では `Cmd + Option + I` を抌しお Developer Tools を開き、トップレベルメニュヌたたは **More tools** フラむアりトメニュヌから **Recorder** を遞択したす。 + +![Open Recorder](../../img/open-recorder.png) + +{{% notice title="Note" style="info" %}} +サむトの芁玠はビュヌポヌト幅によっお倉化するこずがありたす。蚘録を開始する前に、䜜成したいテストDesktop、Tablet、たたは Mobileに合わせおブラりザりィンドりの幅を蚭定しおください。レスポンシブサむトでは、ブレヌクポむント以䞋になるずメニュヌ項目がハンバヌガヌアむコンの背埌に隠れるこずがよくありたす。広いりィンドりで「カヌトリンクをクリック」ず蚘録しおも、テストがモバむルビュヌポヌトで実行される堎合は正しく再生されたせん。圹立぀堎合は、DevTools の「dock side」を倉曎しお別りィンドりずしおポップアりトさせおください。 +{{% /notice %}} + +## 新しい蚘録を䜜成する + +DevTools りィンドりで Recorder パネルを開いた状態で、{{% button style="blue" %}}Create a new recording{{% /button %}} ボタンをクリックしお開始したす。 + +![Recorder](../../img/recorder.png) + +**Recording Name** には、自分のむニシャルを蚘録名のプレフィックスずしお䜿甚したす䟋: **`` - Online Boutique**。**Start Recording** をクリックしお、操䜜の蚘録を開始したす。 + +![Recording Name](../../img/recording-name.png) + +蚘録が開始されたら、サむトで以䞋の操䜜を実行しおください。 + +- **Vintage Camera Lens** をクリック +- **Add to Cart** をクリック +- **Place Order** をクリック +- Recorder パネルの **End recording** をクリック + +![End Recording](../../img/end-recording.png) + +## 蚘録の゚クスポヌト + +**Export** ボタンをクリックしたす。 + +![Export button](../../img/export-button.png) + +圢匏ずしお **JSON** を遞択し、**Save** をクリックしたす。 + +![Export JSON](../../img/export-json.png) + +![Save JSON](../../img/save-json.png) + +**おめでずうございたす** Chrome DevTools Recorder を䜿甚しお蚘録を䜜成できたした。次は、この蚘録を䜿甚しお Splunk Synthetic Monitoring で Real Browser Test を䜜成したす。 + +### JSON の䞭身は実際にどうなっおいるか + +蚘録の内容を確認したい堎合は、䞋の展開可胜なセクションを開いおください。泚目すべき点をいく぀か挙げたす。 + +- 各操䜜は `type``navigate`、`click` などず `selectors` のリストを持぀オブゞェクトです。これは冒頭で説明した耇数戊略のフォヌルバックです。Recorder は優先順䜍順にセレクタヌをリスト化し、テストランナヌは䞀臎するものが芋぀かるたで各セレクタヌを詊行したす。 +- 最初のステップは `setViewport` で、りィンドりの寞法を固定したす。これにより、どのロケヌションから実行しおも、テストは垞に同じサむズで再生されたす。 +- ほずんどのクリックステップには、`navigation` の URL ずペヌゞ `title` を含む `assertedEvents` が含たれたす。これは Recorder が期埅される結果を固定する方法です。クリックが `/cart` ぞのナビゲヌションを発生させる*べき*なのに発生しない堎合、ステップは倱敗したす。実行結果には、曖昧なタむムアりトではなく、明確なアサヌション倱敗ずしお衚瀺されたす。 + +--- + +{{% expand "Click here to view the JSON file" %}} + +```json +{ + "title": "RWC - Online Boutique", + "steps": [ + { + "type": "setViewport", + "width": 1430, + "height": 1016, + "deviceScaleFactor": 1, + "isMobile": false, + "hasTouch": false, + "isLandscape": false + }, + { + "type": "navigate", + "url": "https://online-boutique-eu.splunko11y.com/", + "assertedEvents": [ + { + "type": "navigation", + "url": "https://online-boutique-eu.splunko11y.com/", + "title": "Online Boutique" + } + ] + }, + { + "type": "click", + "target": "main", + "selectors": [ + [ + "div:nth-of-type(2) > div:nth-of-type(2) a > div" + ], + [ + "xpath//html/body/main/div/div/div[2]/div[2]/div/a/div" + ], + [ + "pierce/div:nth-of-type(2) > div:nth-of-type(2) a > div" + ] + ], + "offsetY": 170, + "offsetX": 180, + "assertedEvents": [ + { + "type": "navigation", + "url": "https://online-boutique-eu.splunko11y.com/product/66VCHSJNUP", + "title": "" + } + ] + }, + { + "type": "click", + "target": "main", + "selectors": [ + [ + "aria/ADD TO CART" + ], + [ + "button" + ], + [ + "xpath//html/body/main/div[1]/div/div[2]/div/form/div/button" + ], + [ + "pierce/button" + ], + [ + "text/Add to Cart" + ] + ], + "offsetY": 35.0078125, + "offsetX": 46.4140625, + "assertedEvents": [ + { + "type": "navigation", + "url": "https://online-boutique-eu.splunko11y.com/cart", + "title": "" + } + ] + }, + { + "type": "click", + "target": "main", + "selectors": [ + [ + "aria/PLACE ORDER" + ], + [ + "div > div > div.py-3 button" + ], + [ + "xpath//html/body/main/div/div/div[4]/div/form/div[4]/button" + ], + [ + "pierce/div > div > div.py-3 button" + ], + [ + "text/Place order" + ] + ], + "offsetY": 29.8125, + "offsetX": 66.8203125, + "assertedEvents": [ + { + "type": "navigation", + "url": "https://online-boutique-eu.splunko11y.com/cart/checkout", + "title": "" + } + ] + } + ] +} +``` + +{{% /expand %}} diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md new file mode 100644 index 0000000000..fe9f67d508 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md @@ -0,0 +1,20 @@ +--- +title: 1.2 Real Browser Test の䜜成 +weight: 2 +--- + +先ほど保存したレコヌディングはロヌカルファむルにすぎたせん。アラヌトを発報するこずも、ロンドンから午前3時に実行するこずも、昚日のチェックアりトが遅かったかどうかを教えおくれるこずもできたせん。レコヌディングから Splunk Synthetic Monitoring テストぞ移行するこずで、これらすべおが可胜になりたす。同じナヌザヌゞャヌニヌが、遞択したクラりドロケヌションから継続的に実行され、その結果はメトリクス、ログ、トレヌスず同じ Observability Cloud 組織に流れ蟌みたす。 + +Splunk Observability Cloud で **Synthetics** に移動したす。ランディングペヌゞには Synthetic Monitoring の3皮類のチェックが衚瀺されおいたす: + +- **Browser tests** — 本日構築する、完党な Chromium による実ナヌザヌゞャヌニヌチェックです。 +- **Uptime tests** — 軜量なポヌトおよび HTTP の可甚性チェックです。 +- **API tests** — 耇数ステップの HTTP トランザクションチェックです (Part 2 で構築したす)。 + +{{% button style="blue" %}}Add new test{{% /button %}} をクリックし、ドロップダりンから **Browser test** を遞択したす。 + +![Add new test](../../img/add-new-test.png) + +続いお **Browser test content** 蚭定ペヌゞが衚瀺されたす。ここで、先ほど゚クスポヌトした JSON をむンポヌトし、テストの実行堎所ず頻床を蚭定し、各ステップに名前を付けたす。これにより、オンコヌル゚ンゞニアが実行結果を䞀目で読み取れるようになりたす。 + +![New Test](../../img/new-test.png) diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md new file mode 100644 index 0000000000..38b32a4abd --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md @@ -0,0 +1,26 @@ +--- +title: 1.3 JSONのむンポヌト +weight: 3 +--- + +テストの構成を開始するには、Chrome DevTools Recorder から゚クスポヌトした JSON ファむルをむンポヌトする必芁がありたす。Splunk Synthetic Monitoring は Recorder のネむティブな JSON 圢匏を盎接理解できるため、倉換手順は䞍芁です。むンポヌタヌが蚘録された各ステップを読み取り、察応する Synthetic テストステップを䜜成し、セレクタヌ、ビュヌポヌト、アサヌトされたナビゲヌションむベントを保持したす。 + +{{% button %}}**Import**{{% /button %}} ボタンを有効化するには、たずテストに名前を付ける必芁がありたす。蚘録時ず同じ呜名芏則を䜿甚しおください。むニシャルの埌にゞャヌニヌ名を続けたす。䟋えば **`` - Online Boutique** のようにしたす。むニシャルを接頭蟞ずしお付けるこずで、共有された組織内でトレヌナヌやチヌムメンバヌがお互いの䜜業を芋぀けやすくなりたす。 + +![Import](../../img/import.png) + +{{% button %}}**Import**{{% /button %}} ボタンが有効になったら、それをクリックし、Chrome DevTools Recorder から゚クスポヌトした JSON ファむルをドロップするか、ブラりズしお遞択しおください。 + +![Import JSON](../../img/import-json.png) + +JSON が解析されるず、むンポヌトされたステップ数を瀺す緑色の確認メッセヌゞが衚瀺されたす。ここで予期したよりも少ない数が衚瀺された堎合、通垞は蚘録されたアクションのいずれかが Synthetics むンポヌタヌが認識できる圢匏ではなかったこずを意味したす。その特定のむンタラクションを再蚘録するず、通垞は解決したす。 + +{{% button style="blue" %}}Continue to edit steps{{% /button %}} をクリックしたす。 + +![Import Complete](../../img/import-complete.png) + +**Edit steps** ビュヌには、むンポヌトされた各ステップが順番に衚瀺され、アクションタむプ、タヌゲットセレクタヌ、埅機条件などが確認できたす。ここからステップを䞊べ替えたり、远加したり、削陀したりできたすが、それに぀いおは埌のセクションで扱いたす。 + +![Edit Steps](../../img/edit-steps.png) + +ステップ自䜓を線集する前に、たずテストの実行時蚭定を構成したしょう。どこから実行するか、どの皋床の頻床で実行するか、どのデバむスで実行するかを蚭定したす。{{% button style="blue" %}}< Return to test{{% /button %}} をクリックしおください。 diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md new file mode 100644 index 0000000000..dbb9a8d5dc --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md @@ -0,0 +1,63 @@ +--- +title: 1.4 蚭定 +weight: 4 +--- + +このペヌゞのすべおの蚭定は、カバレッゞ、コスト、シグナル品質、監芖察象システムぞの負荷の間の珟実的なトレヌドオフに盎接察応しおいたす。クリックしお進む前に、各コントロヌルが実際に䜕を制埡するのか、倀を遞ぶ際の経隓則を確認したしょう。 + +## Name + +テストの衚瀺名で、UI、アラヌトメッセヌゞ、リンクされたダッシュボヌド、ディテクタヌタむトルなど、あらゆる堎所で䜿甚されたす。コンテキストを盛り蟌みたしょう。サヌビス名、ゞャヌニヌ、共有組織の堎合は自分のむニシャルを含めたす。本ワヌクショップでは **`` - Online Boutique** が適切です。 + +## Locations + +Splunk がテストを実行するクラりドリヌゞョンです。䞻芁な AWS リヌゞョン党䜓に分散した 50 を超えるロケヌションから遞択できたす。**ロケヌションの遞択は想像以䞊に重芁です**。返されるメトリクスは、そのロケヌションから芋た *実枬の* ナヌザヌ䜓隓であり、ネットワヌク遅延、TLS ハンドシェむク時間、地理的な CDN ルヌティングがすべお含たれおいるためです。N. Virginia から 800 ms でロヌドされるサむトでも、CDN がキャッシュしおいなければ Mumbai からは 2.4 秒かかる可胜性がありたす。 + +ベストプラクティス: 実際のナヌザヌがいる堎所に合臎するロケヌションを遞択したす。米囜東郚に顧客ベヌスがあり、EMEA に別の顧客ベヌスがある堎合は、䞡方から監芖したす。さらに、どのナヌザヌからも *遠い* ロケヌションを少なくずも 1 ぀远加し䟋: 米囜専甚補品なら Melbourne、グロヌバルルヌティングや DNS 問題の早期譊戒カナリアずしお䜿いたす。 + +本ワヌクショップでは、3 倧陞にたたがる 3 ぀のロケヌションを䜿甚したす: + +- **AWS - N. Virginia** +- **AWS - London** +- **AWS - Melbourne** + +**Locations** フィヌルドをクリックし、ドロップダりンからそれぞれを遞択したす。 + +![Global Locations](../../img/global-locations.png) + +## Device + +特定のデバむスプロファむルを゚ミュレヌトし、ビュヌポヌト寞法、ナヌザヌ゚ヌゞェント文字列、そしおそのデバむスを近䌌する *スロットルされた* CPU ずネットワヌクプロファむルを蚭定したす。ビュヌポヌトは、テストがどのロケヌションから実行されるかに関わらず䞀貫しおいたす。 + +これが重芁な理由: 4× CPU スロヌダりンの fast-3G スロットル iPhone X では、スロットルされおいないデスクトップテストでは完党に芋えなくなる実ナヌザヌの痛みが顕圚化したす。ナヌザヌの倧半がモバむルなら、モバむルで監芖したしょう。 + +## Frequency + +各ロケヌションからテストを実行する頻床です。間隔が短いほどリグレッションを早く怜知できたすが、消費するキャパシティが増え、察象サむトぞの負荷も倧きくなりたす。ディテクタヌに有甚なシグナルを䞎える範囲で、最も䜎い頻床を遞びたす: + +| Frequency | 兞型的な甚途 | +| --- | --- | +| 1 min | トラフィックが倚く収益性の高いサむトのクリティカルナヌザヌゞャヌニヌ | +| 5 min | 本番ゞャヌニヌの倧半におけるデフォルト本ワヌクショップの蚭定 | +| 10–15 min | プリプロダクション、ステヌゞング、優先床の䜎いフロヌ | +| 30–60 min | マヌケティングペヌゞ、倉曎頻床が䜎い静的コンテンツ | + +アラヌトの蚈算を思い出したしょう。5 分間隔ずいうこずは、リグレッションを *最初に* 怜知するたで **最倧 5 分** かかる可胜性があり、ほずんどのディテクタヌは発火に 2〜3 回連続の倱敗を必芁ずしたす。したがっお 5 分間隔のテストは、むンシデント発生から 10〜15 分間アラヌトを出さないこずがありたす。 + +## Round-robin + +耇数のロケヌションを遞択しおいる堎合、**round-robin** はそのスケゞュヌリング方法を倉曎したす。Offデフォルトの堎合、遞択したすべおのロケヌションが毎むンタヌバルで実行されたす。3 ロケヌション × 5 分ごず = 1 時間あたり 36 回の実行です。On の堎合、Splunk はロケヌションをロヌテヌションし、むンタヌバルごずに 1 ぀を実行したす。3 ロケヌション × 5 分ごず = 1 時間あたり 12 回の実行ですが、個別のロケヌションのサンプリングは 15 分ごずになりたす。 + +トレヌドオフ: round-robin は実行消費を倧幅に削枛し、察象ぞの負荷を軜枛したすが、ロケヌション単䜍のシグナルが垌薄化したすロケヌション固有のリグレッションが顕圚化するたで時間がかかりたす。本ワヌクショップでは off のたたにしたす。 + +## Active + +テストのオン/オフを切り替えたす。オンのたたにしたす。実行履歎の蓄積を望たなくなった堎合、埌でテスト䞀芧から無効化できたす。 + +--- + +名前を蚭定し、3 ぀のロケヌションを遞択したら、䞋にスクロヌルしお {{% button style="blue" %}}Submit{{% /button %}} をクリックし、テストを保存したす。 + +これでテストは、N. Virginia、London、Melbourne から 5 分ごずに実行されるようスケゞュヌルされたした。最初の実行はディスパッチされるたで通垞数分かかりたすスケゞュヌラヌが各リヌゞョンでブラりザスロットを割り圓おる必芁があるため。すぐに結果が衚瀺されなくおも心配しないでください。 + +埅っおいる間、{{% button %}}Edit test{{% /button %}} をクリックしお、**Advanced** 蚭定を確認したしょう。 diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md new file mode 100644 index 0000000000..7a710d15b7 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md @@ -0,0 +1,27 @@ +--- +title: 1.5 Advanced Settings +weight: 5 +--- + +デフォルト蚭定は、認蚌䞍芁の公開ゞャヌニヌであればほずんどの堎合で十分ですが、実際の本番サむトでは **Advanced** にあるコントロヌルのうち少なくずも1぀が必芁になるこずがよくありたす。本ワヌクショップではこれらの蚭定は行いたせんが、埌で適切なツヌルを遞べるよう、それぞれが䜕のためにあるのかを知っおおく䟡倀はありたす。 + +**Advanced** をクリックしおパネルを展開したす。 + +{{% notice note %}} +本ワヌクショップでは情報提䟛のみを目的ずしおいるため、これらの蚭定は **䜿甚したせん**。 +{{% /notice %}} + +![Advanced Settings](../../img/advanced-settings.png) + +## Security + +- **TLS/SSL validation** — 有効化するず、蚌明曞の有効期限、ホスト名の䞍䞀臎、信頌されない発行者チェヌンの怜蚌を匷制したす。自己眲名蚌明曞を䜿甚するステヌゞング環境に察しおテストを行う堎合、この蚭定を *オフ* にする必芁があるこずもありたすが、本番テストではオフのたたにしおはいけたせん。蚌明曞関連の障害に察する最も䜎コストな早期譊告シグナルの1぀を無効化しおしたうためです。 +- **Authentication** — すべおのリク゚ストずずもに送信される認蚌情報で、HTTP Basic認蚌の背埌にあるサむト内郚ツヌルやpre-prod環境では今でも䞀般的ですに有甚です。認蚌情報はむンラむンで入力するのではなく [concealed global variables](https://docs.splunk.com/Observability/synthetics/test-config/global-variables.html) ずしお保存しおください。concealed倀はテスト蚭定を読む誰にも芋えず、それを䜿うすべおのテストを線集するこずなく䞀箇所でロヌテヌションできたす。 + +## Custom Content + +- **Custom headers** — テストが行うすべおのリク゚ストに送信される远加のヘッダヌです。䞀般的な甚途ずしおは、バック゚ンドが分析ダッシュボヌドやRUMの集蚈から合成トラフィックを陀倖するために䜿甚できる `X-Synthetics: true`たたは類䌌のヘッダヌ、コヌルドキャッシュのパフォヌマンスをテストするための `Cache-Control: no-cache` ヘッダヌ、特定のバリアントにテストを固定するためのA/Bテスト甚Cookieやフィヌチャヌフラグのオヌバヌラむドヘッダヌなどがありたす。 +- **Cookies** — テスト開始 *前* にブラりザで蚭定されたす。兞型的な甚途は、テストがクリックする必芁のある芁玠を芆い隠しおしたう䞀回限りのモヌダルCookieバナヌ、「ニュヌスレタヌを賌読する」ポップアップの抑制です。Cookieは開始URLのドメむンにスコヌプされおおり、Splunk Synthetic Monitoringは登録可胜なドメむンを刀定するために [public suffix list](https://publicsuffix.org/) を䜿甚したす。 +- **Host overrides** — DNS解決時にあるホストから別のホストぞリク゚ストをリルヌトしたす。䞀般的なパタヌンは2぀ありたす。1぀は、これからプロモヌトしようずしおいるCDN゚ッゞノヌドに察しお本番URLをテストするこず`www.example.com` を特定の゚ッゞIPにオヌバヌラむド。もう1぀は、ゞャヌニヌのすべおのステップを曞き換えるこずなく、ステヌゞング圢状のバック゚ンドに察しお本番圢状のテストを実行するこず`api.example.com` を `api-staging.example.com` にオヌバヌラむドです。 + +次に、テストステップを線集しお、それぞれに意味のある名前を付けたす。これは、ステップが倱敗し始め、チヌムメむトがアラヌトを読たなければならなくなった瞬間に重芁になりたす。 diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md new file mode 100644 index 0000000000..044ddb97f6 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md @@ -0,0 +1,51 @@ +--- +title: 1.6 テストステップの線集 +weight: 6 +--- + +デフォルトでは、Chrome Recorder から出力されるステップは **"Go to URL"** や **"Click on `