[PHP] Javascript를 사용할수 없는 환경에서 Google Analytics에 로그 쌓기

Google Analytics는 무료로 사용가능하면서도 매우 강력한 그리고 엄청난 트래픽도 가감없이 처리하여 보여주는 매우 멋진 서비스입니다. 기본적으로 브라우저위에서 동작하며 Javascript를 이용하여 로그를 쌓습니다. 그렇기 때문에 웹브라우저 기반의 서비스가 아닌이상은 이용할수가 없습니다. 좀더 정정해서 말해보자면 이용하기가 쉽지 않습니다. 하지만 역시나 다양한 방법이 존재하더군요. 제가 사용하는 방식을 기억용으로 간단히 기록해 두겠습니다.

웹 서비스 등록 후 PHP 사용으로 변경

사용자 삽입 이미지Analytics 서비스의 가입이나 설정 메뉴에 들어가는 루트등에 대한 언급은 하지 않겠습니다. 추적코드 설정에 들어가게 되면 고급탭에서 모바일 사이트를 선택하실 수 있습니다. 여기서 PHP를 선택하도록 합니다. 이 경우 오른쪽에 자동으로 소스 코드가 생성되는데요 여기서 $GA_ACCOUNT값을 잘 적어둡니다. 여기서 중요한점은 모바일용 GA_ACCOUNT의 값은 MO로 시작합니다.

로깅용 소스코드 작성

[code]// 다음의 값들을 적절하게 정의하여 줍니다.
$deviceOS = ‘[OS정의 (예: iOS/Android)]’;
$userId = ‘[사용자를 식별하기 위한 구분자]’;
$defaultHostName = ‘[로깅을 위한 기본 호스트 도메인]’;
$description = ‘[하나의 로그에 대한 설명, 한글 가능]’;
$gaAccount = ‘[위에서 적어둔 $GA_ACCOUNT값]’;

// 사용자 정보가 없을 경우 랜덤하게 생성
if($userId == null) $userId = uniqid();

// 로깅용 주요 정보 정의
$referer = (!empty($_SERVER[‘HTTP_REFERER’])) ? $_SERVER[‘HTTP_REFERER’] : ‘-‘;
$path = array_shift(explode(“?”, $_SERVER[‘REQUEST_URI’]));
$randomNumber = rand(0, 0x7fffffff);
$timestamp = time();
$domainName =  (!empty($_SERVER[‘SERVER_NAME’])) ? $_SERVER[‘SERVER_NAME’] : $defaultHostName;
$remoteAddress  = $_SERVER[‘REMOTE_ADDR’];

// 구글에서 사용하는 아이피 정보는 C클래스까지만 사용하고 마지막 자리수는 0으로 교체
$regex = “/^([^.]+\.[^.]+\.[^.]+\.).*/”;
$ip = (preg_match($regex, $remoteAddress, $matches)) ? $matches[1] . ‘0’ : ”;

// 사용자 식별 아이디 값 생성
$message = md5($userId);
$visitorId = ‘0x’.substr($message, 0, 16);

// 구글에 요청할 URL 생성
$utmUrl = ‘http://www.google-analytics.com/__utm.gif?’
. ‘utmwv=4.4sh’
. ‘&utmn=’ . $randomNumber
. ‘&utmhn=’ . urlencode($domainName)
. ‘&utmr=’ . urlencode($referer)
. ‘&utmp=’ . urlencode($path)
. ‘&utmac=’ . $gaAccount
. ‘&utmcc=__utma%3D999.999.999.999.999.1%3B’
. ‘&utmvid=’ . $visitorId
. ‘&utmip=’ . $ip
. ‘&utmdt=’ . urlencode($description);

$options = array(
‘http’ => array(
‘method’ => ‘GET’,
‘user_agent’ => $deviceOS,
‘header’ => ‘Accepts-Language: ko’,
‘timeout’ => 1));

$result = @file_get_contents($utmUrl, false, stream_context_create($options));[/code]
위의 코드에서 $utmUrl 주소를 생성할때 다양한 값을 추가할 수 있습니다. [이곳]을 참고하시면 추가적인 정보를 확인해 보실 수 있습니다. 위에서 사용되는 $userId의 경우에는 하나의 값에 대하여 한명의 유니크 방문자로 처리가 되므로 신중이 마구 생성되지 않을 값을 지정해 주셔야 합니다.

위와 같은 복잡한 방법이 귀찮으신 분들에겐 잘 만들어진 [PHP 라이브러리]도 존재합니다.

[Cassandra] 0.8.1로 업그레이드 후 AbstractCassandraDaemon Fatal exception in thread Thread 에러 수정

사용자 삽입 이미지

아직 1.0도 못된 Cassandra를 운영함에 있어 여러가지 이해할수 없는 버그스러운 일이 발생하곤 합니다. 하지만 다행이도 하늘이 무너져도 솟아날 구멍은 항상 있더군요. 이번에도 아주 활당한 경험담을 적어볼까 합니다. 하지만 생각보다 검색해 보면 많은 글이 나오는걸 보면 저와같은 경험담을 가진 사람들이 많을듯 하군요.

잘 운영하던 카산드라 서버를 이번에 새로나온 0.8.1로 업그레이드를 할 경우 다음과 같은 무지막지한 에러를 보게 됩니다.

[code]ERROR [ReadStage:594] 2011-07-22 06:17:20,877 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[ReadStage:594,5,main]
java.io.IOError: java.io.EOFException: EOF after 12559390 bytes out of 842137600
        at org.apache.cassandra.db.columniterator.SimpleSliceReader.<init>(SimpleSliceReader.java:66)
        at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:91)
        at org.apache.cassandra.db.columniterator.SSTableSliceIterator.<init>(SSTableSliceIterator.java:67)
        at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:66)
        at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:80)
        at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1292)
        at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1189)
        at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1146)
        at org.apache.cassandra.db.Table.getRow(Table.java:385)
        at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:61)
        at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:69)
        at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.EOFException: EOF after 12559390 bytes out of 842137600
        at org.apache.cassandra.io.util.FileUtils.skipBytesFully(FileUtils.java:229)
        at org.apache.cassandra.io.sstable.IndexHelper.skipBloomFilter(IndexHelper.java:50)
        at org.apache.cassandra.db.columniterator.SimpleSliceReader.<init>(SimpleSliceReader.java:57)
        … 14 more
 INFO [CompactionExecutor:9] 2011-07-22 06:18:11,575 CompactionManager.java (line 743) Retrying from row index; data is -8 bytes starting at 14898883
 WARN [CompactionExecutor:9] 2011-07-22 06:18:11,575 CompactionManager.java (line 767) Retry failed too.  Skipping to next row (retry’s stacktrace follows)
java.io.IOError: java.io.EOFException: bloom filter claims to be 905969664 bytes, longer than entire row size -8
        at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:149)
        at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:90)
        at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:748)
        at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:633)
        at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:65)
        at org.apache.cassandra.db.compaction.CompactionManager$3.call(CompactionManager.java:250)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.EOFException: bloom filter claims to be 905969664 bytes, longer than entire row size -8
        at org.apache.cassandra.io.sstable.IndexHelper.defreezeBloomFilter(IndexHelper.java:111)
        at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:119)
        … 10 more[/code]
음…좀 이쁘게 보여드리고 싶었는데 달리 방법이 없네요. 위와 같은 에러가 무한정 발생을 하는데요. 위의 에러를 고칠려면 다음의 명령 한방이면 해결이 됩니다. 각각의 노드마다 한번씩 실행해 주셔야 합니다. 보유 데이터량에 따라 소요되는 시간이 다릅니다.
[code]nodetool -h localhost scrub[/code]
scrub 명령은 원하는 키스페이스 또는 컬럼패밀리만을 정하여 sstable을 새로 생성합니다. 기왕이면 서버의 사용량이 적을때를 이용해서 실행하시는것이 정신건강에 좋습니다.

노드만 충분하다면 scrub을 실행하실때에 다음의 명령을 이용하여 서비스 노드에서 제거하시는것이 좋습니다. 이유는 클러스터간에 상태가 꼬여있는 상태(?)일수가 있는데 이경우 scrub을 실행하게 되면 scrub을 실행하는 노드뿐만 아니라 다음의 노드의 부하가 올라가더니 뻗는 경우가 있더군요.
[code]nodetool -h localhost disablegossip[/code]
위의 명령을 실행하게 되면 기존의 노드들간의 클러스터링에서 제외..라는 표현보다는 사라진척 한다는 말이 맞겠네요. 서버들간의 상태를 주고 받는데에 사용되는 gossip을 끄게됩니다. 켤때는 반대로 enablegossip으로 켜주시면 됩니다.

만약에 불가피하게 서비스중에 위의 작업들을 수행해야만 하는 경우라면 클라이언트 소스를 수정할 필요 없이 다음의 명령으로 클라이언트의 요청에 응답해야 할 의무를 버릴 수 있습니다. (thrift를 시용할시)
[code]nodetool -h localhost disablethrift[/code]
마찬가지로 다시 켤때는 반대로 enablethrift를 실행하시면 됩니다.