バックエンド

<instana-agent>/etc/instana/com.instana.agent.main.sender.Backend.cfg を使用してひとつ以上のバックエンドにレポートするように構成する必要があります。 デフォルトでは、エージェントは環境変数 INSTANA_AGENT_ENDPOINTINSTANA_AGENT_ENDPOINT_PORTINSTANA_AGENT_KEY を使用します。 必要な値はデプロイメントによって異なります。

SaaS環境

SaaSのお客様のためのINSTANA_AGENT_ENDPOINT_PORT and INSTANA_AGENT_ENDPOINT は、環境が存在する地域によって異なります。
  • ヨーロッパ:
    • DNS名:ingress-blue-saas.instana.io
    • 宛先ポート:tcp/443
  • アメリカ:
    • DNS名:ingress-red-saas.instana.io
    • 宛先ポート:tcp/443
  • 世界のその他の地域:
    • DNS名:ingress-red-saas.instana.io
    • 宛先ポート:tcp/443

オンプレミスへのインストール

オンプレミスのお客様はインストール中に設定を構成できます。 疑わしい場合は、ポータルからエージェントをダウンロードし、ファイル/etc/instana/com.instana.agent.main.sender.Backend.cfg からオプションをコピーします。

ネットワーク要件

エージェントのセンサーの一部は、エージェントのプロセスの外側で実行されています。 これらのセンサーは、ローカルネットワークを使用してエージェントに接続します。 エージェントとセンサーが同じホストで実行されている場合、これは多くの場合問題ではありませんが、エージェントとセンサー間の正しい通信を確保するには、コンテナー化されたセットアップでの構成が必要になる場合があります。 次の表に、エージェントプロセスに到達するために開く必要があるポートを示します。 デフォルトの42699ポートに加えて、トレースする必要のある言語に基づいて他のポートが必要になる場合があることに注意してください。
センサー ポート範囲 構成可能
エージェントAPI 42699
Javaトレーシング すべての一時ポート
Crystalセンサー 42699 環境変数
Envoy、NGINX、およびその他のプロキシトレース 42699 環境変数
Goセンサー 42699 環境変数
.NETセンサー 42657
Node.jsセンサー 42699 環境変数
PHPセンサー 16816 PHP設定
Node.jsセンサー 42699 環境変数
Pythonセンサー 42699 環境変数
Rubyセンサー 42699 環境変数
Kubernetes環境では、外部センサーがエージェントに到達したり、その逆に到達したりできるように、ネットワークポリシーでエージェントポッドとサービスポッド間の接続を許可する必要があります。 参照:言語センサー

コンフィギュレーション

Instanaエージェントコンフィギュレーションは、次の場所にあるひとつの中央構成ファイルを使用して採用できます。 <agent_install_dir>/etc/instana/configuration.yaml 重要configuration-abc.yaml というファイルを作成して、ファイルシステムの順序でこのファイルとマージすることができます。 したがって、configuration-cde.yaml configuration-abc.yaml の後に来ます。 タグのようなネスト構造のみがマージされ、値は後続の構成によって上書きされます。 このファイルの形式はYAMLであり、これは空白に非常に敏感です。 すべてのインデントレベルで許可されるのは 2つの空白スペースのみです。

追加のファイルシステム

デフォルトでは、エージェントはローカルファイルシステムのみを監視します。 ファイルシステムを追加するには、ファイルシステムの名前(mtabまたはdfの最初の列)を追加します。

たとえば、次のファイルシステムを監視するには:

server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr

ホストセクションのコメントされていないファイルシステムリストに次の行を追加してください:

com.instana.plugin.host:
  filesystems:
    - 'server:/usr/local/pub'

タグ

エージェントの特定のタグは、com.instana.plugin.host セクションで次の形式で指定できます。
com.instana.plugin.host:
  tags:
    - 'production'
    - 'app1'
あるいは、環境変数 INSTANA_TAGS=production,app1 を使用することもできます(環境変数と構成ファイルのタグは追加可能です)。 これにより、特定のエージェントに2つのタグが追加されるため、UIでタグの検索とフィルタリングが可能になりました。

インストール済みパッケージリスト(デフォルトでは無効)

configuration.yaml ファイルで collectInstalledSoftware
true に設定すると、オペレーティングシステムにインストールされているパッケージを1日に!回抽出できます。

現在、次のLinuxディストリビューションがサポートされています。

  • Debianベース(dpkg)
  • RedHatベース(rpmおよびyum)
com.instana.plugin.host:
  collectInstalledSoftware: false #  valid values: true, false

カスタムゾーン

Instanaは、デフォルトでAmazon Web Services、Google Compute Engine、またはOpenStack Novaのアベイラビリティゾーン情報を使用してホストをグループ化します。 このホストのグループ化をカスタマイズするには、特定のホストのグループを次の形式を使用してセクションcom.instana.plugin.generic.hardware で定義できます。
com.instana.plugin.generic.hardware:
  enabled: true
  availability-zone: 'Demozone'
または、代わりに環境変数 INSTANA_ZONE=Demozone を代わりに使用できます(環境変数のゾーンが構成ファイルのゾーンをオーバーライドします)。 その結果、ホストはマップ上のゾーンにグループ化されます。

カスタムプロセス

Instanaは、デフォルトでJavaやMySQLなどの高レベルセンサーのプロセスメトリックを自動的に監視します。 Instanaによって自動的にカバーされないOSプロセスを監視する場合は、プロセス名または引数、あるいはその両方を使用して設定できます。

com.instana.plugin.process:
  processes:
    - 'sshd'
    - 'slapd'
  arguments:
    - '/opt/script.sh'

シークレット

トレースデータには機密データが含まれる場合があります。 したがって、Instanaエージェントは、「シークレット」のパターンの仕様、つまり、トレースデータからエージェント側で編集されるデータの仕様をサポートしています。 シークレットとして扱われるデータは、処理のためにInstana SaaSに到達しないため、UIでの分析やAPIを介した取得には使用できません。

Instanaは、一致するシークレットの仕様をサポートしています。

  • 環境変数
  • JDBC接続文字列
  • Dockerコンテナ情報
  • HTTPクエリパラメータ(実質的にサポートされるすべてのランタイムについては、以下のサポートマトリックスを参照)、例:https://my.domain/accounts/status?account=&user=
  • HTTPマトリックスパスパラメーター。たとえば、https://my.domain/accounts/account=;user=/status (一部のランタイムでサポートを利用できます。以下のサポートマトリックスを参照してください)
LanguageHTTPクエリパラメータのシークレットHTTPマトリックスパラメーターのシークレット
Java
Go  
.NET Framework 
.NET Core  
.NET Framework 
Node.js 
PHP
Python 
Ruby  
Crystal  

:GoインスツルメンテーションはOpenTracing APIに基づいているため、シークレットの処理はインストルメント側が行います。

:Instanaは、URLがhttps://my.domain/accounts//status として構成されている場合など、URLパス内の任意のセグメントをシークレットとして扱うことをサポートしていません。 たとえば、URLパスで正規表現を実行してセグメントを破棄するオーバーヘッドは、非常に高くなります。

(さらに、実際にはシークレットに関連する問題ではありませんが、InstanaエージェントはストアドプロシージャからSQLパラメーターをキャプチャしません。任意のパスセグメントの場合と同様に、SQLクエリからリテラルを削除せず、パラメータ化されたクエリの仕様を強くお勧めします。)

シークレットは、サポートされているすべての言語に対して次の方法で指定されます。

com.instana.secrets:
  # One of: 'equals-ignore-case', 'equals', 'contains-ignore-case', 'contains', 'regex'
  matcher: 'contains-ignore-case'
  list:
    - 'key'
    - 'password'
    - 'secret'

センサーによって収集されたキーがリストのエントリと一致する場合、値は編集され、Instanaバックエンドに送信されません。 カスタムシークレット構成を指定しない場合、エージェントはデフォルトで前述のシークレット構成を使用します。

:一般に、シークレットは静的データからフィルタリングされます。 フィルタリングは最適化されており、プロセスの実行中は変更が適用されません。 シークレット構成を有効にするには、エージェントまたは実行中の監視対象コンポーネントを再起動します。これらは新しい構成を尊重する必要があります。

:選択したKubernetesリソースでの追加のシークレットリダクションについては、Kubernetesシークレットで詳細をご覧ください。

カスタムHTTPヘッダーのキャプチャ

デフォルトでは、InstanaはHTTP呼び出しをトレースするときにHTTPヘッダーを収集しませんが、この機能はオンデマンドで有効にできます。 そのためには、キャプチャするヘッダーを指定する必要があります。

com.instana.tracing:
  extra-http-headers:
    - 'x-request-id'
    - 'x-loadtest-id'
    - ...

値は大文字と小文字を区別しません。 このようにして収集されたヘッダーは、コールの詳細(「呼び出し先の詳細」セクション)に表示されます。 それらを使用して、呼び出しとトレースを検索することもできます(UI内およびAPI経由)。 最後に、サービス構成に使用できます。

制限

  • InstanaはHTTPエントリーリクエストヘッダーのみをキャプチャします (HTTPは、インストルメントされたプロセスが受け取ると呼び出します)。
  • InstanaはJavaおよびNode.jsでHTTPのエントリーのレスポンスヘッダーをキャプチャします。
  • InstanaはHTTP終了時にヘッダーをキャプチャしません(インストルメントされたプロセスがクライアントであり、HTTPサーバーがインストルメントされていない場合にHTTPが呼び出します)。
  • この機能は現在、Java、.NET、NodeJ、PHP、Python、およびRubyでサポートされています。

プロセスの無視

特定のプロセスの監視を無視するには、com.instana.ignore セクションのコメントを外し、監視しないプロセスのすべてのプロセス名をリストします。 スクリプトまたは他のジョブが同じコマンドで開始されることもありますが、ひとつのコマンドの実行のみを無視する必要があります。 この場合、引数を使用して、プロセスを無視させる引数を指定します。

com.instana.ignore:
  processes:
    - 'java'
    - 'httpd'
  arguments:
    - '-batch-file=/tmp/batch.def'

UIによってトリガーされるエージェント機能を無効にする

Instana Agentログを追跡し、エージェントで診断アクションを実行し、トレースコードビューを有効にするために、ユーザーはInstana UIを介してこれらの機能をトリガーできます。 これらのすべての機能を無効にしたい場合は、以下に追加して構成を設定できます: <agent_install_dir>/etc/instana/com.instana.agent.main.config.Agent.cfg
backchannel.enabled = false

instanaへのCodesourceファイルの送信を無効にします

Instanaエージェントは、監視するプロセスのソースコードをオンデマンドで取得し、収集されたトレースデータに関連付けることができます。 Instanaへのソースファイルのオンデマンドアップロードを無効にするには、 <agent_install_dir>/etc/instana/com.instana.agent.main.config.Agent.cfg ファイルで以下の構成を設定できます。
source.download.enabled = false
:この設定を適用するには、Instanaエージェントを再起動する必要があります。

SDK設定

SDKの構成については、Java Trace SDKのドキュメントページをご覧ください。

エージェントのロギング構成

デフォルトでは、Instana Agentは /data/log/agent.log にログを記録しますが、ファイルが大きくなりすぎるとローテーションされます。 コンテナでエージェントを実行している場合は、代わりにコンソールにログが記録されます。コンソールはDockerによって管理され、Dockerログからアクセスできます。

構成ファイル /etc/org.ops4j.pax.logging.cfg のレベルを

log4j2.logger.instana.level=INFO

から

log4j2.logger.instana.level=DEBUG 変更することにより、ログレベルをデバッグ用に増やすことができます。

行の末尾に空白がないことを確認してください。

古いエージェントのインストールでは、この行を

log4j.logger.com.instana=INFO, out, osgi:*

から

log4j.logger.com.instana=DEBUG, out, osgi:* 変更する必要があります。

ログローテーション

デフォルトでは、エージェントは5MBのエージェントログファイルの10倍のログローテーションを使用します。

log4j2.appender.rolling.policy.type = SizeBasedTriggeringPolicy
log4j2.appender.rolling.policy.size = 5MB
log4j2.appender.rolling.strategy.type = DefaultRolloverStrategy
log4j2.appender.rolling.strategy.max = 10

Syslogを構成する

エージェントは、Log4j2を使用するようになりました。これは、最新の柔軟なロギング機能です。 たとえば、syslogは次のように構成できます。

log4j2.rootLogger.appenderRef.Syslog.ref = Syslog
log4j2.rootLogger.appenderRef.Syslog.level = ERROR
log4j2.appender.syslog.type=Syslog
log4j2.appender.syslog.name=Syslog
log4j2.appender.syslog.layout.type=PatternLayout
log4j2.appender.syslog.layout.pattern = ${log4j2.pattern}
log4j2.appender.syslog.facility=SYSLOG
log4j2.appender.syslog.host=localhost
log4j2.appender.syslog.port=514
log4j2.appender.syslog.protocol=UDP

STDOUTへのロギング

カスタムコンテナイメージでは、STDOUTにログを記録できます。 これを行うには、 <instana-agent-install-dir>etc/org.ops4j.pax.logging.cfg で次の構成を提供します。
log4j2.rootLogger.appenderRef.Console.ref = Console

log4j2.appender.console.type = Console
log4j2.appender.console.name = Console
log4j2.appender.console.layout.type = PatternLayout
log4j2.appender.console.layout.pattern = ${log4j2.pattern}

Log4j2

ロギングは標準のlog4j2ロギングを使用しているため、log4j2のドキュメントで説明されているように、より多くの方法で構成できます。

エージェントプロキシのセットアップ

背景

バックエンドと効果的に通信するために、InstanaはHTTP / 2プロトコルを使用してデータを転送します。 多くの場合、エージェントからバックエンドへの直接通信が許可され、エージェントの展開が簡素化されます。 場合によっては、ネットワークへの専用の出入りが必要です。 このため、Instanaはさまざまなプロキシと組み合わせて使用​​できます。 一般に、http(s)、socks4s、およびsocks5プロキシがサポートされています。 プロキシは、CONNECTパススルーをサポートする必要があります。 注:SSL接続を終了してからInstanaバックエンドへの独自の接続を管理しようとするプロキシはサポートされていません。 ALPNを使用しないセキュアHTTP / 2を使用します。

Instanaエージェントの構成

Instanaエージェントの構成では、2つのファイルを変更する必要があります。 ファイル <install-dir>/etc/mvn-settings.xml では、<settings> </settings> セクション内に次の情報が存在する(かつコメントアウトされていない)必要があります。
<proxies>
  <proxy>
    <id>agent-proxy</id>
    <active>true</active>
    <protocol>http</protocol>
    <username>user-if-needed</username>
    <password>password-if-needed</password>
    <host>your-proxy-address-goes-here</host>
    <port>your-proxy-port-goes-here</port>
  </proxy>
</proxies>
これにより、Instanaエージェントはエージェントの更新と追加機能を自動的にダウンロードできます。 さらに、エージェントとInstanaバックエンド間の通信にプロキシを使用するには、ファイル <install-dir>/etc/instana/com.instana.agent.main.sender.Backend.cfg を再構成する必要があります。 次の行が存在し、コメントアウトされていないことを確認してください。
proxy.type=http
proxy.host=your-proxy-address-goes-here
proxy.port=your-proxy-port-goes-here
proxy.user=user-if-needed
proxy.password=password-if-needed
proxy.dns=true

サンプルSquidプロキシのセットアップ

このドキュメントでは、使用可能な他のプロキシがない場合、Instanaと組み合わせたsquidプロキシ(www.squid-cache.org)の構成について説明します。 システムにSquidをインストールする方法はいくつかあります。 ほとんどのLinuxディストリビューションのリポジトリにはSquidが含まれており、優先パッケージマネージャーを使用してソフトウェアをインストールできます。 パッケージが利用できない場合、またはMicrosoft WindowsでSquidを実行する場合は、http://wiki.squid-cache.org/SquidFaq/BinaryPackagesからSquidバイナリを入手できます。 Squidがインストールされると、squid.conf という設定例が作成されます。 Instana通信専用にプロキシを使用する場合は、デフォルトの構成をバックアップして、この最小限の squid.conf を使用できます:
# The tcp port squid is listening on
http_port 3128

# Please specify subnet with instana agents
acl instana_agent_net src 10.0.0.0/8

# This is the ip of the instana backend
acl instana_backend dstdomain ingress-blue-saas.instana.io
#acl instana_backend dstdomain ec2-54-144-114-141.compute-1.amazonaws.com
#acl instana_backend dstdomain saas-us-east-1.instana.io
#acl instana_backend dstdomain saas-us-east-1.instana.io

# This is the port used by Instana
acl instana_backend_port port 443

# This is the repo to download updates and additional sensors
acl instana_repo dstdomain artifact-public.instana.io
acl instana_repo_port port 80
acl instana_repo_port_secure port 443

# Protocol used for instana backend
acl instana_backend_proto proto HTTP

# Protocol used for instana backend
acl instana_repo_proto proto HTTP
acl instana_repo_proto_secure proto HTTPS

http_access allow instana_agent_net instana_backend instana_backend_port
http_access allow instana_agent_net instana_repo instana_repo_port
http_access allow instana_agent_net instana_repo instana_repo_port_secure

# DO NOT REMOVE THIS RULE!
http_access deny all

エージェントのバージョン管理と更新管理

背景

Instanaエージェントは、管理作業がほとんどないように最適化されています。 管理オーバーヘッドを削減するための重要な機能のひとつは、エージェントとすべてのセンサーのバージョンを自動的に管理する自動更新機能です。 いくつかのシナリオでは、この更新メカニズムでは、最新バージョンに自動的に更新するだけでなく、より詳細な構成が必要です。

更新間隔の構成

デフォルトでは、エージェントは毎日午前4時30分頃に新しいバージョンをチェックします。 この自動チェックはオフにするか、別の時刻を優先するように設定したり、特定の日にのみ実行したりできます。

設定はファイル etc/instana/com.instana.agent.main.config.UpdateManager.cfg で行われ、デフォルトでは次のようになります。

# Instana Update Manager configuration.
# AUTO for automatic updates with given schedule. OFF for no automatic updates.
mode = AUTO
# DAY for daily, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY
every = DAY
# Time is hh:mm in 24 hours format.
at = 04:30

静的バージョンの選択

センサーまたはエージェントバージョンのすべての変更は、新しい「現在のセット」バージョンの完全なセットとして自動更新リポジトリに事前にリリースされます。 以前にリリースされたすべてのセットは、https://github.com/instana/agent-updatesから入手できます。git(エージェントの更新に対するすべての変更を追跡するバージョン管理システム)で、これらの各セットは「sha」という静的バージョンナンバーが与えられます。
version = <sha>
と設定することで特定のセットを選択することが可能です。 起動前に etc/instana/com.instana.agent.bootstrap.AgentBootstrap.cfg ファイルで その後、エージェントはこのバージョンセットにとどまり、新しいバージョンに更新されることはありません。

現在のバージョンの凍結

Instanaリポジトリ Instanaエージェントには、更新を検索するための事前構成済みのリポジトリのセットがあります(必要に応じて追加のリポジトリを構成できます)。 デフォルトのエージェント設定では、エージェントには、ネットワーク上の中央リポジトリへのアクセスに加えて、フォルダ <agent-dir>/data/repo にローカルリポジトリがあります。 このフォルダーには、このセットアップにとって重要ではないフォルダのうち、XNUMXつのInstana機能用の特定のフォルダが含まれます。
  • /com/instana/agent-feature/
  • /com/instana/discovery-feature/
  • /com/instana/sensor-feature/
現在のエージェントバージョンの凍結 これらの各機能には、利用可能なバージョンに関する詳細情報を記述したファイルがあります。 たとえば、フォルダ<agent-dir>/data/repo/com/instana/sensor-feature/1.0.0-SNAPSHOT には、センサー機能のバージョンに関する情報を含むファイルがあります。 これで、すべての機能リポジトリをフォルダ<agent-dir>/data/repo/com/instana/ からターゲットフォルダ<agent-dir>/system/com/instana にコピーし、そこからエージェントがフィーチャーを優先的にロードできます(例:cp -r <agent-dir>/data/repo/com/instana/*-feature/ <agent-dir>/system/com/instana/)。 これにより、エージェントはそれ自体を更新せず、この凍結バージョンのままになります。 :自動更新は、構成された間隔で引き続き実行されます。 上記の構成ファイルが更新された場合、自動更新は次回の実行時に新しいバージョンをプルします。

現在のバージョンの取得

エージェントとセンサーのバージョンをインストールするために、次のエージェントAPIエンドポイントを使用できます。 curl localhost:42699/version

異なる環境でのエージェントのCPUとメモリの制限

特定のシナリオでは、プロセスのリソース消費を非常に厳密に制御することが重要です。 これは、リソース共有を活用する環境や、リソースが非常に少ないシステムで特に便利になります。 Instanaエージェントはできるだけ少ないリソースを消費するように設計されていますが、明確なリソース制限を尊重するための別の保護手段として、以下の手順に従って制限することができます。 以下のすべての例では、エージェントのCPUをCPUの半分(ただし、すべてのリソースが必ずしも同じCPUに由来するとは限らない)および最大512 MBのメモリに相当するコンピューティングリソースに制限します。

systemd

/etc/systemd/system/instana-agent.service.d/20-resource_limits.confというファイルを作成し、次のコンテンツを追加します。

[Service]
CPUAccounting=true
CPUQuota=50%
MemoryAccounting=true
MemoryMax=512M

systemctl daemon-reloadを実行して、instana-agentサービスを再起動します。

Docker

以下の追加パラメーターを使用して、instana-agentコンテナーを実行します。

バージョン1.13以降:

--cpus=0.5 --memory=512m

バージョン1.12以前:

--cpu-period=100000 --cpu-quota=50000 --memory=512m

Kubernetes

次の構成スニペットをエージェントのコンテナー構成に追加します。
livenessProbe:
  httpGet: # Agent liveness is published on localhost:42699/status
    path: /status
    port: 42699
  initialDelaySeconds: 75
  periodSeconds: 5
resources:
  requests:
    memory: "256Mi"
    cpu: "0.5"
  limits:
    memory: "512Mi"
    cpu: "1.0"
上記の構成では、instana-agent コンテナのメモリとCPUの要求も少なくなります。

複数のバックエンドの構成

背景

場合によっては、エージェントが複数のバックエンドにレポートすることが望ましい場合があります。 たとえば、厳密に分離された環境で使用される共有サービスの場合。 そのようにエージェントを手動で構成することができます。 エージェントはすべてのバックエンドでライセンスの消費としてカウントされ、これはエージェントの帯域幅消費を効果的に増加させることに注意してください。

Instanaエージェントの構成

ファイル <install-dir>/etc/instana/com.instana.agent.main.sender.Backend.cfg は、エージェントが送信する単一のバックエンドを構成するために使用されます。 複数のバックエンドを使用するには、このファイルの名前を <install-dir>/etc/instana/com.instana.agent.main.sender.Backend-1.cfg に変更し、<install-dir>/etc/instana/com.instana.agent.main.sender.Backend-2.cfg <install-dir>/etc/instana/com.instana.agent.main.sender.Backend-3.cfg などという名前のコピーを作成してください。その後、各ファイルを調整して、異なるバックエンドとエージェントキーを記述したり、異なるプロキシ設定を含めることもできます。 123の代わりに、英数字のユニークIDを使用できます。 エージェントに複数のバックエンドを尊重させるには、元のファイル <install-dir>/etc/instana/com.instana.agent.main.sender.Backend.cfg が存在しないことが重要です。 Docker化されたエージェントが複数のバックエンドにレポートできるようにするには、Agent Dockerセットアップドキュメントを参照してください。

メトリックスまたはトレースをファイルに記録する

エージェントは、そのエージェントを介してディスク上のファイルに送信されるメトリックまたはトレースを一時的に記録できます。 これは、メトリック、トレース、トレース、またはスパンに関連するさまざまな問題をデバッグするためによく使用されます。 これを有効にするには、ファイル <agent_install_dir>/etc/instana/com.instana.agent.main.sender.File.cfg を見つけて、その内容を次のように更新します。
# Configuration of local logging. Changes will be hot-reloaded.
# Activate logging of outgoing payloads to local disk by setting a non-empty
# prefix. The log file will be written to data/log, and the file will have the
# defined prefix followed by a timestamp.
# Note: There is no automatic rotation of those files.
prefix=locallog

# The file can be filtered to either "metrics" or "traces".
# If empty or absent, there will be no filtering.
type=traces
前述のように、変更はホットリロードされ、すぐにアクティブになります。 これを有効にしたままにすると、十分な時間とトラフィックが与えられると、利用可能なすべてのディスク領域が一杯になる可能性があるため、これは一時的にのみ行う必要があります。 問題のコンポーネントへのトラフィックを生成している間、ログを1、2分継続します(問題をトレースする場合)。 次に、変更を元に戻すか、そのファイル内のすべての行をコメント化します。 繰り返しますが、ディスクに書き込まれた変更は、Instanaエージェントによってホットリロードされます。 サポートチケットを使用している場合は、結果のログファイルをサポートチケットに添付してください。 ログファイルは <agent_install_dir>/data/log/locallog_*.log にあります。

エージェント管理

Instanaに報告するすべてのエージェントには、独自のダッシュボードがあります。 各ダッシュボードにはエージェントのリアルタイム情報が表示され、モード、ログレベルの設定、エージェントの更新、エージェントとセンサーのリセットを行うことができます。

エージェントダッシュボードへのアクセス

次のいずれかを使用して、エージェントダッシュボードに移動できます。

ホストダッシュボードのOpen Agent Managementボタン:

または、トップレベルナビゲーションの「More」メニューから「Agents」を選択。 ここで、特定のエージェントを検索できます。 FQDN列のエンティティリンクをクリックすると、エージェント管理ダッシュボードが表示されます。

Instana Agentダッシュボード

エージェントモード

エージェントモードは、ホストベースのライセンスを使用して、エージェントがインフラストラクチャエージェントまたはAPMエージェントのどちらとしてカウントされるかを決定する場合に関連します。 これは、「Change Agent Mode」を使用して切り替えることができます。

このドロップダウンは、モード「オフ」もサポートします。 これにより、バックエンドへの「ハートビート」以外のすべてのエージェント機能がオフになります。 エージェントをオンに戻すことが可能であり、エージェントは、以前の場所から再びピックアップします。

インフラストラクチャのみで、すべてのトレース関連機能がオフになります。

このモードは、設定ファイルinstana-agent/etc/instana/com.instana.agent.main.config.Agent.cfg からも設定できます。

mode = APM
# APM or INFRASTRUCTURE or OFF

instana-agent/etc/instana/com.instana.agent.main.config.Agent.cfg 構成ファイルを変更するには、エージェントを再起動して有効にする必要があります。

通知: One-Linerエージェントのインストール方法とInstanaエージェントのDockerイメージは、AWS モードと呼ばれる追加モードを受け入れます。 AWS モードは、AWS APIデータドキュメントを監視するためのInstanaエージェントのインストールで説明されているように、単にINFRASTRUCTURE モードとAWSデータ収集の一部の自動構成です。

エージェントとセンサーのリセット

ダッシュボードは、必要に応じてセンサーまたはエージェント全体をリセットすることもできます。

一部のメトリックが欠落しているときにセンサーをリセットすることは、利用可能な最も軽量な修正アクションです。

エージェント全体のリセットは、エージェントプロセスの再起動と非常に似ていますが、プロセスはアクティブなままです。 これは、OSレベルのウォッチドッグ/サービススクリプトがプロセスIDの変更を認識しないことを意味します。

センサー情報

このポップアップには、ホストに存在するセンサーとエージェントコンポーネントのリストが、各コンポーネントの名前、バージョン、状態とともに表示されます。 このリストは検索可能です。

エージェントの自己監視

さらに、Instanaエージェントは、継続的な軽量の自己監視を行います。 メトリックを使用して、エージェントのパフォーマンスとリソース消費を監視できます。

エージェントヒープダンプ

問い合わせをサポートする必要がある場合は、このコマンドを実行してInstanaエージェントのヒープダンプを作成できます。

TS=`date +%s` && /opt/instana/agent/jvm/bin/jmap -dump:file=/tmp/agent-dump-$TS.hprof `cat /opt/instana/agent/agent.pid` && gzip /tmp/agent-dump-$TS.hprof