Sending HTTP error to APM from Angular shows error.custom.<name> field in Kibana

Kibana version : 7.6.2

Elasticsearch version : 7.6.2

APM Server version : 7.6.2

APM Agent language and version : @elastic/apm-rum-angular 1.1.1. Angular 9.1.0

Browser version : Firefox 76.0b8

Original install method (e.g. download page, yum, deb, from source, etc.) and version : Used the Angular Integration instructions

While trying to Query Kibana for HTTP status code error, I see that these custom fields are not indexed and thus not filterable. It's weird that these even show up as custom at all, I would imagine that Elastic should know that these are HTTP errors and would match it accordingly to a field in Kibana.

See image, note error.custom.<name> (why are these being created?):

This is how I'm sending the error from Angular:

constructor(@Inject(ApmService) service: ApmService) {
    this.apmService = service.init({
      serviceName: 'frontend',
      serverUrl: 'http://localhost:8200/',
      serviceVersion: '1.0.0',

      username: 'John',
      id: '001',

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    return next.handle(req).pipe(
      catchError((error: HttpErrorResponse) => {
        let errorMessage = '';
        if (error.error instanceof ErrorEvent) {
          // client-side error
          errorMessage = `Error: ${error.error.message}`;
        } else {
          // server-side error
          errorMessage = `Error: ${error.status} - ${error.message}`;
        this.apmService.captureError(error, { response: error.status });
        return throwError(errorMessage);

How do I send this error to APM so that Kibana correctly knows to fill this in with the correct fields it has?

Hi Edgar,

The Angular Error type HTTPErrorrResponse is a custom one and has many properties that does not match with the common Error format which has name,message, stack, columnno, lineno and so on. The common error properties are indexed correctly to exception which is already defined mapping. All the other error properties are intentionally added to the custom context as it would help the users to debug the issues faster.

There is no special treatment given to the HTTP based errors at this point in the APM server as of this date. As you have mentioned already, the custom context is not indexed as it can contain arbitrary information which might not be useful in all scenarios.

To go back to how we can do this correctly, 404 is a valid response and the HTTP span would contain all the information related to the request (eg: status, url etc). Hope it helps. Let me know if you have any further questions.


This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.