Implementations for application-specific log routing are described. An example method may include receiving, by an application server, a log message; responsive to determining that a log router associated with the application server is enabled, identifying a thread context associated with an execution thread that created the log message; responsive to identifying a logger associated with the thread context, forwarding the log message to the logger; and processing the log message by the logger.

A semiconductor device includes a data bus, a data memory, a selector, a processor, and a debug controller. The selector is configured to be controlled by the debug controller to be in either a first selecting state in which the processor transmits a first signal to the data bus and a second selecting state in which the debug controller transmits a second signal to the data bus. The debug controller is configured to control the state of the selector based on the reception state of a predetermined command from an external device as well as the states of a read enable signal and a write enable signal from the processor such that, when the selector is in the second selecting state, the debug controller accesses the data bus via the selector.

An offset address generator generates a plurality of offset addresses at an interval of a basic processing unit size on the basis of an access destination address from a calculating circuit, partitions an access destination memory region from the calculating circuit to set a plurality of verification address ranges. A determiner sequentially determines whether the plurality of set verification address ranges are matched with a monitoring target address. With this configuration, it is possible to simplify the configuration of a debug function in a processor.

A system receives real-time log messages from an executing process that experiences a runtime error. Information such as a filename and line number for the underlying source code may be embedded in the log messages using compiler macros. When the log messages are received, a developer URL may be generated that links a developer workstation directly to the underlying source code file and line number in a source code repository. A support URL may also be generated with a link to a support center and an embedded search string that retrieves resources that are known to address the process error.

An error logging system is provided that is configured to automatically create a type introspection database from a compiled application that was written using the C programming language. During execution of the application, if there is an error, the executing application will generate an unstructured error log which is passed to an error logging system. The type introspection database enables the error logging system to parse the unstructured error log to create a corresponding structured error log. The error logging system includes generic display, search, and share functions. The display function is configured to display the name, value, and type, of every attribute in each data structure. The search function provides a way to determine if the structured error log satisfies a selection criteria specified on one or more attributes of the data. The share function enables the error logging system to export the structured error logs.

An instrumentation overhead regulation technique regulates an amount of work performed by a client library of an investigative platform used to monitor, diagnose and solve errors associated with application development and production. The client library calculates processing resources utilized during its runtime activity to enable adjustment of the amount of work it performs based on the measured activity. An agent may determine the overhead activity impact to user application performance by monitoring processing resource metrics of the user application. The agent analyzes the calculated overhead and processing resource metrics to render decisions to automatically regulate the capture fidelity of the client library. Regulation of the capture fidelity may be implemented by modifying parameters of a dynamic configuration. If results of the analysis indicate a potential issue, the amount of work the client library performs may be trimmed to ensure that the calculated overhead of the client library and its impact on user application performance does not exceed a predetermined threshold.

Embodiments of the present disclosure present devices, methods, and computer readable medium for techniques for measuring operational performance metrics, and presenting these metrics through an application programming interface (API) for developers to access for optimizing their applications. Exemplary metrics can include central processing unit or graphics processing unit time, foreground/background time, networking bytes (per application), location activity, display average picture luminance, cellular networking condition, peak memory, number of logical writes, launch and resume time, frame rates, and hang time. Regional markers can also be used to measure specific metrics for in application tasks. The techniques provide multiple user interfaces to help developers recognize the important metrics to optimize the performance of their applications. The data can be normalized over various different devices having different battery size, screen size, and processing requirements. The user interfaces can provide an intelligent method for visualizing performance changes for significant changes in application versions.

Execution status of managed time series processing tasks may be tracked. Status of a time series processing task that operations on different portions of a time series may be respectively captured. A request for the status of one of the portions of the time series with respect to the time series processing task may be received. The status may be identified and returned. For failed tasks, a failure reason may be generated by the time series processing system and included in a response with a failure status.

A method of analyzing a performance of a microservices-based application comprises generating a plurality of traces from a plurality of spans associated with the microservices-based application. The method also comprises generating a plurality of data sets each associated with a respective analysis mode of a plurality of analysis modes using the plurality of traces, wherein each analysis mode extracts a different level of detail for analyzing the performance of the services in the application from the plurality of spans. Further, the method comprises selecting, based on a first user query, a first analysis mode from the plurality of analysis modes for generating a response to the first user query. The method also comprises accessing a data set of the plurality of data sets that is associated with the first analysis mode and generating the response to the first user query using the data set associated with the first analysis mode.

Techniques and devices are described for embedding data in an address stream on an interconnect, such as a memory bus. Addresses in an address stream indicate at least part of a location in memory (e.g., a memory page and offset), whereas data embedded in the address stream can indicate when metadata or other information is available to lend context to the addresses in the address stream. The indication of data in the address stream can be communicated using, for example, a mailbox, a preamble message in a messaging protocol, a checksum, repetitive transmission, or combinations thereof. The indication of data can be recorded from the address stream and may later be used to interpret memory traces recorded during a test or can be used to communicate with a memory device or other recipient of the data during testing or regular operations.