I am trying to set up OpenTelemetry in a distributed Nodejs application. I am using elastic APM to view those traces and respective spans. For exporting those span data to elastic APM I have an otel Collector on K8s. The issue is that I can see the span events in elastic index but those span event details are not visible in traces' logs as mentioned here
Is there any work around for this?
This was because of a bug in elastic APM version 8.4.0 as mentioned here . It can be fixed by upgrading to any version above 8.4.1 that it 8.4.2 or 8.5. It can also be fixed by downgrading to a version below 8.4.0. For me version 7.0.0 worked.
Related
I'm relying on Node version 12.17.x to make use of a specific feature (AsyncLocalStorage) in Lambda and Elasticbeanstalk. But for some reason, the Node.js version does not seem to publicly available. Why do they think that platform "12.x" tells me the real Node version? I want to know the exact minor and patch version, or at least give some news about it...
I had to create a test lambda function that prints process.version, but surprisingly, platform 12.x still uses v12.16. When will they upgrade to the latest stable version that came out more than 2 weeks ago? Are they publishing those releases somewhere? Google tells me nothing useful.
The same applies to Elasticbeanstalk instances. Node v12.17 does not exist in /opt/elasticbeanstalk/node-install/*
I've just checked in our sentry and the current version is newer-v12.18.4 so you can safely use AsyncLocalStorage now on v12 lambdas.
But AWS should really show this in the lambda administration panel. The fact that this is not shown anywhere and we have to use console logs or third party tools to get this info is a very poor DX.
Hi everyone!
I have "ELK" (6.4.2) working perfectly with filebeat, metricbeat, packetbeat and winlogbeat in CentOS 7 x86_64 (Kernel 3.10.0-862.11.6.el7.x86_64).
I'm trying to integrate zipkin + elk (see https://logz.io/blog/zipkin-elk/), but Elasticsearch does not create indices with Kibana.
When trying to create the indices in Kibana, the process does not end. (Follow logs below).
I suspect the zipkin connection drivers are not compatible with elk 6.4.2. Has anyone had the same problem and has a "light at the end of the tunnel"?
Tks for all!
Java version:
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
Zipkin startup:
java -DSTORAGE_TYPE=elasticsearch -DES_HOSTS=http://localhost:9200 -jar /opt/zipkin.io/bin/zipkin.jar
Error log in Elasticsearch:
[2018-10-24T11:31:59,933][WARN ][o.e.d.i.m.MapperService ] Setting index.mapper.dynamic is deprecated since indices may not have more than one type anymore.
[2018-10-24T11:31:59,936][WARN ][o.e.d.i.m.MapperService ] [_default_] mapping is deprecated since it is not useful anymore now that indexes cannot have more than one type
[2018-10-24T11:31:59,954][WARN ][o.e.d.i.m.MapperService ] Setting index.mapper.dynamic is deprecated since indices may not have more than one type anymore.
[2018-10-24T11:32:00,033][WARN ][o.e.d.c.m.MetaDataCreateIndexService] index or alias name [zipkin:span-2018-10-24] containing ':' is deprecated and will not be supported in Elasticsearch 7.0+
[2018-10-24T11:32:00,245][WARN ][o.e.d.i.m.MapperService ] Setting index.mapper.dynamic is deprecated since indices may not have more than one type anymore.
[2018-10-24T11:33:47,717][WARN ][o.e.d.a.a.i.t.p.PutIndexTemplateRequest] Deprecated field [template] used, replaced by [index_patterns]
Here is the related issue:
we also mentioned recently that for data to appear, applications need to be
sending traces
https://github.com/openzipkin/zipkin#quick-start
you can tell also by hitting the /metrics endpoint and look at stats named
collector
https://github.com/openzipkin/zipkin/issues/1939
I opened a issue on the zipkin github, a theme already being treated as a bug.
Initial thread:
https://github.com/openzipkin/zipkin/issues/2218#issuecomment-432876510
Bug track:
https://github.com/openzipkin/zipkin/issues/2219
Tks for all!
I set up a new EC2/Node instance via the Elastic Beanstalk console, but I'm unable to upgrade NodeJS as the button is grayed out.
I tried changing the version of NodeJS in the configuration section, but it didn't upgrade it. In the past either of the options have worked, but I'm not sure why the button is grayed out? I've also tried deploying a sample application and other (supported) versions of NodeJS in the config. I've tried restarting and rebuilding the environment with the new config, but it defaults to Node v4.3.0.
Has anyone encountered this? Am I missing something here? Thanks!
EDIT: This guide states that the option to change configuration is available only when a new compatible version of the platform is available. However, I'm interested in updating NodeJS and not the overall OS.
Those are 2 different things, v4.3.0 (in first image), is the version of the Amazon Linux OS. Is not related to node.
The second image shows the node version you are using (6.10.0). You can tweak that in the config dialog
Im use a Elasticsearch 5.1.2 (docker installation) and integrated with a project generated with jHipster 4.0.2.
After configure Elasticsearch, Elastic show the message:
java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.1.2]
sn_elasticsearch |
Its posible to upgrade the client version of Spring Data Elastic integration in jHipster project? Someone knows how to?
[]s
spring-data-elasticsearch does not support version 5 yet. It is a work in progress by a team of volunteers (not driven by the Spring Data team).
According to the latest post on GitHub where you can track the issue:
Given that we will look into upgrading elasticsearch to latest version and as #olivergierke suggested it will be released with Kay if we will be able to merge changes before RC1 which is in mid March [2017].
This pull request still require major week or two of a work, its not straight forward merge. We are independent resource(s) willing to contribute on this project wherever we can, anyone who is willing to do the same is more than welcome to contribute.
We will keep posting update from our side about upgrade on the same thread.
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.