15

I set up my analytics tracker code as someone noted to me in another question, but when I went through my site and did a login, then some stuff, then logged out (causing a session abandon), the analytics portal on Sitecore still registered the user as anonymous. Going back through the instructions, I saw that the Analytics.ClusterName had to be changed as well to match the CD DNS or IP. So I did that on my local to 127.0.0.1.

After I made that change and reset the site, however, I got a YSOD screen with the "Tracker.Current is not initialized" error. When I look at the logs, I see an error for "Cannot push session url: http://default-cd-cluster/sitecore/service/analytics/session/PushSession.ashx" followed by "The remote name could not be resolved: 'default-cd-cluster'". I confirmed in ShowConfig.aspx that the correct setting was made to Analytics.ClusterName.

If I change it back to the default, the site at least comes up again. I don't understand why the error is happening in this case, though, if that's not the setting I have after the fact. This is with Sitecore 8.1 Update 1.

Improve this question
1
  • Does your site resolve on the server to 127.0.0.1? Or does it require a fqdn?
    – Chris Auer
    Commented Feb 17, 2017 at 19:02

3 Answers 3

Reset to default
22

Cannot Create Tracker or Tracker.Current is Not Initialized - Common Fixes

Your problem is that after changing the Analytics.Clustername, you are not ensuring that the hostname (which is really what ClusterName is) is resolvable. All Servers must be able to resolve the ClusterName by DNS. Either by a host file entry locally on the server or through a DNS server.

See http://default-cd-cluster/sitecore/service/analytics/session/PushSession.ashx, unless default-cd-cluster is defined somewhere on your local host file or DNS, default-cd-cluster does not resolve. On CD instances, this has to resolve to local host (127.0.0.1), but on CM's this has to resolve to a CD instance IP address.

By the way, in single instance mode, where CM and CD are combined, I almost never change the ClusterName from defaults, because it'll work just fine. User of Analytics.ClusterName is only super important in a distributed role environment (separated CM and CD's).

See Below for insight and details on why this is occurring and how to fix it.

Reason 1: Analytics.ClusterName is configured incorrectly.

The Analytics.ClusterName which is set in the Sitecore.Analytics.Tracking.config needs to be a legitimate, resolvable hostname. The default "default-cd-cluster" is not enough to promote a working solution. This value has to be a dns name that all Sitecore Servers can reach (e.g. cd.cluster.domain.com for example).

  • Ensure that each server, at a minimum has the configured Analytics.ClusterName in the windows host file and configured to point to an IP address of a Content Delivery server.
    • If on a content delivery server, set this host file IP equal to localhost, which is 127.0.0.1.
    • If on a content management or other server, set the host file IP value equal to the IP of ONE of your CD servers. Do not set it to the load balancer IP (unless that can be reached by your network)

Reason 2: Analytics.Hostname is Incorrect

It has been my experience that setting a value for Analytics.Hostname, located in the Sitecore.Analytics.Tracking.config file does more harm than good. I have found leaving this value BLANK, makes everything work as it should.

Reason 3: Sitecore.Context.Page is not available.

Sitecore's Analytic Tracker requires that the Sitecore.Context.Page object be available in order for Tracker to be initialized. In certain cases where this object is not available, and Tracker tries to be started, it will throw this error.

Tracker cannot be utilized on ASHX's, internal pipelines or thread processes where Page is not set.

Utilization of Tracker on Content Management Servers.

Pure (role configured) Content Management servers do not utilize session state management, and therefore can not run Tracker natively. Instead, they rely on the Analytics.ClusterName to resolve in order to communicate a session back to the Content Delivery servers. In cases where on the Content Management server, you receive these types of errors, it is because Analytics.ClusterName is not correctly setup and reachable.

This also applies to Processing Servers, EXM Dispatch Servers, and Secondary Content Management Servers.

Want a Deep Dive Look?

Here is a link to a blog post that I just published today as a result of this answer. In addition, I go into a deep dive behind the covers to reveal what's really going on when the Tracker is initialized and WHY the Analytics.ClusterName is so important.

Improve this answer
4

On Sitecore 9 this error can also happen if your custom facet model json files on xconnect don't match the custom model you have defined in your DLL. Make sure you deploy your new json model file to all the places that xconnect needs them or the tracker will not initialize.

This is a good reference that explains how custom facets work and how to generate the json file and where to put it. Primarily the "Deploying Custom Collection Models to xConnect" section.

https://citizensitecore.com/2017/10/17/xconnect-adding-custom-facets-in-sitecore-9/

Improve this answer
2
  • Your answer worked for me. Thanks
    – Himmat Singh Dulawat
    Commented Apr 25, 2019 at 12:39
  • 1
    According to doc.sitecore.com/developers/92/… "In Sitecore 9 and later, the parameter Analytics.ClusterName in the Sitecore.Analytics.Tracking.Config file is no longer used, and should be left at its default value."
    – Ian G
    Commented Jun 23, 2020 at 14:45
-1

I am trying to set up local Environment from my Dev server. I am trying to use same DEV DB. I am using same code base as Dev on my local environment other than changing IP to local one. Site was working for sometime but suddenly I am getting same error as "Tracker.Current is not initialized". I have referred above solution but still i am getting same error. I am using v8.2

Can you help me on this?

Improve this answer
2
  • Please raise a new question. Else this has a high chance of getting lost.
    – NutsAndBolts
    Commented Jan 3, 2020 at 11:24
  • in 8.2 I ran into this issue on my local as well because my instance of Mongo DB was stopped. Once I restarted that service via the bat file, I was back in business.
    – MikeD
    Commented Feb 4, 2020 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.