About Kenji_Kumada

Kenji_Kumada · ‎10-05-2022

Hi @Arthur.Valijan, Thank you for your post to the community! From the given information, it is difficult to give the exact approach you need. As the error message says, the element is no longer accessible but this happens for different reasons, due to the website structure, network latency, the server environment, the client environment, etc. I found these pages and maybe they will help you to understand the issue and take a next step. https://www.softwaretestingmaterial.com/stale-element-reference-exception-selenium-webdriver/ https://stackoverflow.com/questions/12967541/how-to-avoid-staleelementreferenceexception-in-selenium As you mention it rather happens randomly, I would like to suggest to execute the script many times locally and take some statistics. It may reveal facts for the error, like on which element it happens more, in which time range happens more, etc. We also have documentation for waiting for DOM Elements. https://docs.appdynamics.com/appd/22.x/latest/en/end-user-monitoring/synthetic-monitoring/browser-synthetic-monitoring/synthetic-scripts/wait-for-dom-elements Hope this answer helps. Best regards, Kenji

Kenji_Kumada · ‎10-05-2022

Hi, @Ashwitha.G Claudia has already shared the documentations to get started. As for the question of synthetic recorder, there is no recorder within Appdynamics. However, you can use external recorder such as Katalon. This is the documentation https://docs.appdynamics.com/appd/22.x/latest/en/end-user-monitoring/synthetic-monitoring/browser-synthetic-monitoring/synthetic-scripts/write-your-first-script Katalon recorder can export recording to Appdynamics Python format. Best regards, Kenji

Kenji_Kumada · ‎10-04-2022

Hi @Alex.Oliveira, I have checked the implementation for this URL filtering feature in the Java agent in version 22.9.0, the latest version as of now. This feature matches the specified "match-pattern" against the whole URL, not against each segment content. After finding matches against the URL, it masks the segments specified in the configuration regardless of the segments' content. I tested your configuration <sensitive-url-filter delimiter="/" segment="3,4,5,6" match-filter="REGEX" match-pattern=":" param-pattern="myParam|myAnotherParam"/> with this URL http://dummy.com:443/seg2/seg3/seg4/seg5/seg6/seg7?myParam=1&yourParam=2 It resulted in http://dummy.com:443/seg2/*****/*****/*****/*****/seg7?myParam=*****&yourParam=2 This is because `:` matches in the http protocol and segments 3, 4, 5 and 6 are specified. When I changed match-patter from ":" to "=", the result was the same http://dummy.com:443/seg2/*****/*****/*****/*****/seg7?myParam=*****&yourParam=2 This is because '=' matches in the last segment `seg7?myParam=1&yourParam=2`. This is different from the result you described when you put match-pattern=":". This may be due to different java agent versions or different java environments. If you share information about your environment and example URLs, maybe we can investigate further. Best regards, Kenji

Kenji_Kumada · ‎09-27-2022

Hi @Anonymous.Checa Grande, Thank you for your post to the community! From the given information, I see two possible issues that caused the crash. * the environment varialbe "AWS_Execution_Env" doesn't seem correctly set * unzipping the extension to /opt/extension This message "AWS_Execution_Env is not supported, running lambda with default arguments." is from the appdynamics extension script. This message is shown when the execution environment is not Python or Node.js. Could you check if the environment variable "AWS_EXECUTION_ENV" is set? I wrote out the environment variable and in my environment with python 3.7, it was set as "AWS_Lambda_python3.7". https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#:~:text=function%20is%20executed.-,AWS_EXECUTION_ENV,-%E2%80%93%20The%20runtime%20identifier For the second issue, it is not clear whether you should unzip to /opt or /opt/extension. It doesn't seem necessary to put your extention in /opt/extension if it's internal extension. You can have a look to this link. https://alanstorm.com/customizing-the-behavior-of-aws-lambda/ By the way, I followed the instructions in "Add the AWS Lambda Extension to Your Function when packaged as a container image" section in this documentation page https://docs.appdynamics.com/appd/22.x/latest/en/application-monitoring/install-app-server-agents/serverless-apm-for-aws-lambda/use-the-appdynamics-aws-lambda-extension-to-instrument-serverless-apm-at-runtime and it worked fine. You can have a look and see if there is any inconsistent setting in your container image. In this setting, the appdynamics extension script is located in /opt, not /opt/extension. It may be that it crashed because the extension script is executed as an external extension (as you put it in /opt/extension) but I cannot conclude with the provided information. Hope this answer helps! Best regards, Kenji

Kenji_Kumada · ‎09-14-2022

Hi @Vincent.DUBOIS Thank you for your post to the community! Yes, the SAM (Service Availability Monitoring) has reached end of life. As stated in the following link: https://docs.appdynamics.com/paa/appdynamics-support-advisories/support-advisory-service-availability-monitoring-end-of-life-eol-notice A replacement for this functionality is AppDynamics synthetics API monitoring. https://docs.appdynamics.com/appd/22.x/latest/en/end-user-monitoring/synthetic-monitoring/synthetic-api-monitoring However, if you are interested only in the availability of a webpage, and not a web service, browser synthetic monitoring may be better. https://docs.appdynamics.com/appd/22.x/latest/en/end-user-monitoring/synthetic-monitoring/browser-synthetic-monitoring You can also use this url-monitor-extention with the machine agent. https://developer.cisco.com/codeexchange/github/repo/Appdynamics/url-monitoring-extension https://docs.appdynamics.com/appd/22.x/22.3/en/infrastructure-visibility/machine-agent/extensions-and-custom-metrics Best regards, Kenji

Kenji_Kumada · ‎09-08-2022

Hi @Tausif.Ahmad Thank you for your post to the community! If your environment is a Saas environment, one option is to use "now" function. https://docs.appdynamics.com/appd/21.x/21.5/en/analytics/adql-reference/adql-queries/analytics-functions This function returns a datetime value. From this value, you can create another datetime value for the current date at 00:00, and use it in "WHERE" clause. This is an example: SELECT eventTimestamp, application, toString(eventTimestamp, 'yyyyMMdd-HH:mm') AS eventTimestampString, toString(now(), 'yyyyMMdd') AS currentDateString, toDate(currentDateString, 'yyyyMMdd') AS currentDate FROM transactions WHERE (eventTimestamp - currentDate) > 0 LIMIT 100 Note that comparing two datetime fields or comparing a datetime field and a returned value by "now" function may not work. But you can use the result of subtraction for a condition as in the example. If your environment is not Saas, unfortunately, there is no straightforward way to do this. It may be possible to use "SINCE ... UNTIL" clause or "series" function but it depends on the data. And probably it may require some data manipulation. Here is the documentation for "SINCE ... UNTIL" clause and "series" function. https://docs.appdynamics.com/appd/21.x/21.1/en/analytics/adql-reference/adql-queries/since-until-clause https://docs.appdynamics.com/appd/21.x/21.5/en/analytics/adql-reference/adql-queries/analytics-functions Hope this answer helps! Best regards, Kenji

Kenji_Kumada · ‎09-05-2022

Hi @Rao.Srinivasa, Thank you for your post to the community! I could not see the detail of the data you were using and the health rule configuration but it seems like the shown standard deviation range is too low, i.e., 0 to 2.09E-1 and this indicates that the default baseline was not computed properly and not available yet for health rule condition. This may be due to the values of calls per minute are too low or there is not enough data to create the baseline, and they may have resulted in invalid health rule configuration. Baselines are not computed for metrics if there are fewer than 20 calls per minute and also it takes some time to collect data and create initial baselines. You can have a look to this documentation to check how baselines are dynamically created. https://docs.appdynamics.com/appd/22.x/22.6/en/application-monitoring/business-transactions/monitor-the-performance-of-business-transactions/dynamic-baselines You can check whether the health rule configuration was evaluated successfully in the Health rule configuration screen. When it was not evaluated, you see the question mark icon with grey background. When it is successfully evaluated, you should see the green checked icon. To make sure the health rule is evaluated, you can try setting a specific value or using another baseline, not the default baseline. After that, you can configure the health rule following this documentation to meet your requirement. https://docs.appdynamics.com/appd/22.x/22.6/en/appdynamics-essentials/alert-and-respond/configure-health-rules/create-and-configure-conditions As for setting health rule condition for your specific example, using "Baseline percentages" with 30% may be an option. Please see "Baseline Percentages" in the documentation above. Note that it is important to set a proper baseline before using conditions with the baseline percentage. For setting a proper baseline, the "Use Baselines to Identify Trends" section in the same documentation may help you. Best regards, Kenji

Kenji_Kumada · ‎08-25-2022

Hi @Anonymous, Thank you for your post to the community! I have checked the latest java agent version 22.7.0 and it seems you cannot collect HTTP request types and status codes using http data collector. In order to collect HTTP request types and status codes, you can use MIDC instad of HTTP data collector. First idntify class and method that you can collect these information and define MIDC data collectors. In my environment with a simple springboot application, I was able to get HTTP request type with the following MIDC configurations. * Class: org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter * Method Name: invokeHandlerMethod * Collect Data From: Method Parameter @index 0 * Operation on Method Parameter: User Getter Chain, getMethod You can get status code from the same method but with * Collect Data From: Method Parameter @index 1 * Operation on Method Parameter: User Getter Chain, getStatus Hope this answer helps! Best regards, Kenji

Kenji_Kumada · ‎08-17-2022

Hi @Simon.Spehar, Thank you for your post to the community! Unfortunately, there is no such troubleshoot manual for data collection configuration. To troubleshoot misconfiguration issues, you need to check whether your manual data collector is configured as described in the documentation below and check logs for the agent that sends the data to the controller. The agent could be the standalone analytics agent, Java agent, .Net agent or machine agent depending on your environment. Documentation for Configure Manual Data Collectors: https://docs.appdynamics.com/appd/21.x/21.6/en/analytics/configure-analytics/collect-transaction-analytics-data/configure-manual-data-collectors Documentation specifically for SQL data collector: https://docs.appdynamics.com/appd/21.x/21.2/en/analytics/configure-analytics/collect-transaction-analytics-data/collect-business-data-from-sql-calls The logs that would be useful are mentioned in the "General Troubleshooting Issues" section of this documentation: https://docs.appdynamics.com/appd/22.x/22.2/en/analytics/troubleshoot-analytics-issues For the example you mentioned that you can not select the custom field (I'm assuming you can see the default fields but only the custom fields are not visible.), the most common cause is that configuration is not set right. For method invocation collector, this could be due to the wrong class name, method name, operation on a method parameter, etc. This is one example of misconfiguration in the operation on the method parameter. You would find a log entry like below in agent.<timestamp>.log : [http-nio-8080-exec-10] 17 Aug 2022 14:44:06,853 WARN InstrumentationPointUtil - Invalid configuration, could not find method parameter at index[3], maximum length of parameters for method [doGet] is [2] com.singularity.ee.agent.appagent.services.transactionmonitor.error.common.spi.NoStackTraceThrowable: Invalid configuration, could not find method parameter at index[3], maximum length of parameters for method [doGet] is [2] Another example is the wrong class name in the data collector configuration. In this case, you don't see any WARN or ERROR message in agent.<timestamp>.log but you would notice that `ByteCodeTransformer.<timestamp>.log` doesn't have the class name you expect to match with your data collector configuration. When it matches, you should see the class name you specified like this: [http-nio-8080-exec-1] 17 Aug 2022 10:47:51,632 INFO - Matching class name HelloWorld [http-nio-8080-exec-1] 17 Aug 2022 10:47:51,632 INFO - Matching class bytecode. : Class match found. [http-nio-8080-exec-1] 17 Aug 2022 10:47:51,633 INFO - Applying method interceptor data.POJOGatherer at HelloWorld.doGet ((Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) id:66 As you can see, how you find misconfiguration in the logs depends on which configuration is not correct. And this also depends on which data collector and which analytics agent you are using. But the basic idea to troubleshoot is to check the logs. Hope this answer helps! Best regards, Kenji

Kenji_Kumada · ‎08-11-2022

Hi @Rahul.Pola, Thank you for your post to the community! Unfortunately, the frequency for the metrics data from the metrics REST APIs is not configurable. It is internally set based on the provided time interval and duration. In general, shorter duration gives smaller frequency. You can use the following table as a rough reference (This may be different in versions.) Duration in mins <= 260 = 1 min frequency 260 < Duration in mins <= 2940 = 10 min frequency 2940 < Duration in mins = 60 min frequency Please keep it in mind that the controller rolls up the old metrics data as per the policies. Therefore, requesting short duration for an old time range gets larger frequency than the one mentioned above. You can have a look to this documentation for the retention and deletion policy: https://docs.appdynamics.com/appd/22.x/22.5/en/appdynamics-essentials/metrics-and-graphs/metric-data-resolution-over-time You can check the retained data with the smallest granularity in the metrics browser's graph. This is also described in the documentation. There was a similar question in the community. This also may help you to understand the behavior. https://community.appdynamics.com/t5/Controller-SaaS-On-Premises/Metric-Data-using-REST-API-Faulty-frequency-in-older-timestamps/td-p/47665 Hope this answer helps! Best regards, Kenji

Posts	10
Solutions	2
Karma Given	4
Karma Received	18
Member Since	‎07-19-2022

Online Status	Offline
Date Last Visited	3 weeks ago

Re: selenium.common.exceptions.StaleElementReferen...

Re: AppDynamics Synthetic Monitoring

Re: Java app-agent-config.xml - use of regex to ma...

Re: APM Serverless Lambda. Python extension crash....

Re: uptime metrics of a web page

Re: How to put a date and time condition in a ADQL...

Re: Alert configuration for low volume of calls

Re: How Do I get HTTP Request methods(GET,POST,DEL...

Re: Troubleshooting manual data collectors

Re: Can the frequency tag be configurable in rest-...