Versions Compared

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Published by Scroll Versions from this space and version 20.8
    Sv translation
    languageen

    Overview

    Selected fields in the analytics data are "analyzed". Analysis consists of tokenizing a block of text into individual terms suitable for use in an inverted index and normalizing these terms into a standard form to improve their searchability. The ADQL Comparison Operators behave differently for analyzed and non-analyzed fields. To construct queries on analyzed fields, you need to understand some concepts about how the tokens are built.

    Uppercase letters in analyzed fields are all converted to lowercase to build tokens. 

    Delimiters and other factors (such as CamelCase terms) affect how strings are tokenized. For a string such as "myname@company.com",  "@" is a delimiter, therefore myname and company.com are two separate tokens. Additionally, company.com is two separate tokens. Note that all non-alphanumeric characters are delimiters. A term that uses CamelCase, such as VicePresident, is tokenized into separate tokens based on recognition of the CamelCase nature of the term resulting in the tokens: Vice and President as well as VicePresident.

    For an example string such as:  <VicePresident:SalesAndMarketing> - EMEAAustraliaUSA94107, the tokens generated include the following:

    • vicepresident
    • vice
    • president
    • salesandmarketing
    • sales
    • and
    • marketing
    • emeaaustraliausa94107
    • emeaaustraliausa
    • emea
    • australia
    • usa
    • 94107

    Analytics Analyzed Fields

    The analyzed fields in analytics events are the following:

    • Logs: Message
    • Transactions: Errors and Error Detail
    • Mobile: stacktrace

    Queries on Analyzed Fields

    Full-text search is supported on analyzed fields, including the message field for logs, using the LIKE operator. See Comparison Operators for details on using LIKE.

    On analyzed fields, the REGEXP operator matches exactly only the analyzed and processed tokens, so you cannot query across the complete message.

    Consider this log message: 

    No Format
    [2016-06-09 06:07:50,118] [INFO ] [org.springframework.jms.listener.DefaultMessageListenerContainer#0-1] [com.appdynamics.provision.OrderMessageListener] [AD_REQUEST_GUID[2b8ce807-986c-45f9-a5b4-2fe5a6fd90f3]] Received a message to process the order Order_3138 for the user myname@company.com

    In this log message, myname and company.com are two separate tokens because "@" is a delimiter. To search a log message like this for results based on the email address requires searching across tokens. 

     A query such as the following using REGEXP, will fail because myname and company.com are two separate tokens. 

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message REGEXP ‘myname@company.* 

    The LIKE operator is not affected by delimiters, so an alternative query using LIKE operator is a better choice.

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message LIKE ‘myname@company'

    You can also use wildcards in the query because they work across tokens.

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message LIKE ‘myname@company*'

    Example Queries for Analyzed Fields

    Searching the following analytics log events:

    No Format
    Jun 7 11:27:45 appd sshd[1032]: Illegal user test from 110.49.183.11
    Jun 7 11:27:46 appd sshd[1032]: Failed password for illegal user test from 110.49.183.11 port 9218 ssh2
    Jun 7 11:27:46 appd sshd[1032]: error: Could not get shadow information for NOUSER

    Note the results from the following queries:

    QueryResults
    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'illegal.+user'

    Does not match any log events in the sample because the query string spans across multiple tokens. Use LIKE for an instance like this.

    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'illegal.*'

    Matches the first two log events

    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'Failed*'Does not match any log events in the sample because the token has only lowercase ‘failed'

     To search for string : javaIOException

    Query
    SELECT * FROM transactions WHERE application = 'yourAppAND segments.errorList.errorCode REGEXP 'java[a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]'
    Sv translation
    languageja

    Appd tocbox

    ADQL Reference:

    Page Tree
    rootADQL Reference

    概要

    分析データの選択したフィールドは「分析」されます。分析は、反転インデックスでの使用に適した個々の用語にテキストブロックをトークン化(分割)することと、検索を向上させるためのそれらの用語を標準形式に正規化することから構成されます。分析対象フィールドと分析対象外フィールドでは、ADQL Comparison Operators の動作は異なります。分析対象フィールドに対してクエリを作成するには、トークンの作成方法に関するいくつかの概念を理解する必要があります。

    分析対象フィールドの大文字はすべて小文字に変換され、トークンが作成されます。 

    区切り文字やその他の要因(キャメルケースの用語など)も、文字列のトークン化方法に影響します。「myname@company.com」などの文字列の場合、「@」は区切り文字であり、したがって、myname と company.com は 2 つの別個のトークンです。さらに、company.com も 2 つの別個のトークンです。英数字以外の文字はすべて区切り文字であることに注意してください。VicePresident など、キャメルケースを使用する用語は、用語のキャメルケース特性の認識に基づいて個別のトークンにトークン化され、結果のトークンは VicePresident、および VicePresident となります。

    <VicePresident:SalesAndMarketing> - EMEAAustraliaUSA94107 のような文字列の例では、生成されるトークンは次のようになります。

    • vicepresident
    • vice
    • president
    • salesandmarketing
    • sales
    • and
    • marketing
    • emeaaustraliausa94107
    • emeaaustraliausa
    • emea
    • australia
    • usa
    • 94107

    Analytics 分析対象フィールド

    分析イベントの分析対象フィールドは次のとおりです。

    • Logs:メッセージ
    • Transactions:エラーとエラーの詳細
    • Mobile:スタックトレース

    分析対象フィールドに対するクエリ

    LIKE 演算子を使用して、ログのメッセージフィールドなどの分析対象フィールドに対してフルテキスト検索を実行できます。LIKE の使用について詳しくは、Comparison Operators を参照してください。

    分析対象フィールドでは、REGEXP 演算子は分析対象トークンと処理対象トークンにのみ正確に一致するため、メッセージ全体に対してクエリを実行することはできません。

    次のログメッセージについて考えてみます。

    No Format
    [2016-06-09 06:07:50,118] [INFO ] [org.springframework.jms.listener.DefaultMessageListenerContainer#0-1] [com.appdynamics.provision.OrderMessageListener] [AD_REQUEST_GUID[2b8ce807-986c-45f9-a5b4-2fe5a6fd90f3]] Received a message to process the order Order_3138 for the user myname@company.com

    このログメッセージでは、「@」が区切り文字であるため、myname と company.com が 2 つの個別のトークンになります。このようなログメッセージを検索して、電子メールアドレスに基づく結果を見つけるには、トークン全体を検索する必要があります。 

    myname と company.com が 2 つの別個のトークンであるため、REGEXP を使用した次のようなクエリは fail となります。 

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message REGEXP ‘myname@company.* 

    LIKE  演算子 は、区切り文字の影響を受けません。 そのため、LIKE 演算子を使用した別のクエリを選択するのが適切です。

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message LIKE ‘myname@company'

    また、ワイルドカードはトークン全体に対して動作するため、クエリでワイルドカードを使用することもできます。

    No Format
    SELECT FROM logs WHERE appName = 'yourAppName' AND sourceType = 'yourLogFile' AND message LIKE ‘myname@company*'

    分析対象フィールドに対するクエリの例

    次の分析ログイベントを検索します。

    No Format
    Jun 7 11:27:45 appd sshd[1032]: Illegal user test from 110.49.183.11
    Jun 7 11:27:46 appd sshd[1032]: Failed password for illegal user test from 110.49.183.11 port 9218 ssh2
    Jun 7 11:27:46 appd sshd[1032]: error: Could not get shadow information for NOUSER

    次のクエリの結果に注目してください。

    クエリ結果
    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'illegal.+user'

    クエリ文字列が複数のトークンにまたがっているため、サンプル内のどのログイベントとも一致しません。このようなインスタンスには LIKE を使用します。

    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'illegal.*'

    最初の 2 つのログイベントに一致します。

    SELECT * FROM logs WHERE sourceType='yourLogFile' AND message REGEXP 'Failed*'トークンには小文字の「failed」しかないため、サンプル内のどのログイベントとも一致しません。

     文字列を検索するには:javaIOException

    クエリ
    SELECT * FROM transactions WHERE application = 'yourAppAND segments.errorList.errorCode REGEXP 'java[a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z][a-z]'