GoogleAnalyticsメモ
ユーザ
https://support.google.com/analytics/answer/2992042?hl=ja
ユーザとは、Analyticsからcookieに振られたUserIDで判別される。
つまりブラウザが変われば別ユーザとカウントされる。
セッション
https://support.google.com/analytics/answer/2731565?hl=ja
セッションとは1ユーザのひとまとまりの行動
以下でリセットされる。
- 時間による期限切れ: - 操作が行われない状態で 30 分経過した後 - 午前 0 時 - キャンペーンの切り替わり: - キャンペーン経由でサイトにアクセスして離脱した後、別のキャンペーン経由でサイトに戻ってきた場合
GoogleAnalytics APIメモ
https://ga-dev-tools.appspot.com/query-explorer/ https://support.google.com/analytics/answer/1008004?hl=ja
所感
cookieベースでユーザとセッションを測定しているので、アクセスログだけから同じ精度の集計を行うのは難しい。
アクセスログからはページビューを出すくらいが限度かな。
BigQueryのクエリ料金メモ
BigQueryのクエリ課金にビビっていたので、課金ルールを確認した。
- テーブルスキャンした対象の列のデータ量に応じて課金される
SELECT *
やると全列分に課金されるので、必要な分だけに絞る。
- インデックスはないのでフルスキャン
- whereに何書いてもフルスキャンされる
- テーブル分割することでスキャン対象を絞ることができる
- キャッシュ
- クエリの結果は匿名データセット(=キャッシュ)に保存される
- クエリはまずキャッシュがあるかチェックする
- キャッシュを返す場合はコストゼロ
- dry-runで走査するデータ量を確認できる
- dry-runはbqコマンドのオプション指定で実行できる
- 2021-01-05時点でconsoleからはできない模様 → でもクエリ実行前に走査量は確認できる
- link
ChefZero覚え書き
はじめてChefZeroのコード読むことになったので、調べたこと覚え書き。
インストール
ここからDL https://downloads.chef.io/products/chefdk
knife-zeroインストール
chef gem install knife-zero --no-document
node
# 対象サーバのリストを出力する knife node list # 環境をリスト出力する knife environment list # 環境(development)を作る knife environment create development # サーバ追加 # サーバに接続してサーバ情報をnodes/test_node.jsonに書き出す # 情報もりもりなので、.chef/knife.rb で knife[:automatic_attribute_whitelist] を指定して書き出す属性を絞ったほうがいい knife zero bootstrap test-server.com:<ポート> -x test_user --sudo -N test_node # nodeに実行するrecipeを追加 knife node run_list add 'test_node' 'recipe[sample_cook::default]' # recipe実行 # knife zero converge QUERY (options) knife zero converge name:test_node -x test_user --sudo
.chef/knife.rb
knife[:automatic_attribute_whitelist] = %w( fqdn/ os/ os_version/ hostname ipaddress/ roles/ recipes/ ipaddress/ platform/ platform_version/ )
cookbook
# cookbook作成 chef generate cookbook cookbooks/sample_cook # recipeを作る例 # cookbooks/sample_cook/recipes/default.rb package 'vim' do action :install end
role
Chefにおけるロールとは、同じ役割のサーバをまとめて管理するための仕組みである。 例えばWebサーバーが5台あった場合、同じ設定をサーバごとに用意しては手間が増えるしミスの可能性も高くなるが、 webというロールを用意して、webロールに対してランリストなどを記述することにより、個別のサーバーへの設定はロールを適用するだけで済むようになる。
## 作成 bundle exec knife create my_role ## 編集 bundle exec knife edit my_role
roles/my_role.json
{ "name": "my_role", "description": "", "json_class": "Chef::Role", "default_attributes": { }, "override_attributes": { }, "chef_type": "role", "run_list": [ "recipe[xxx]" ], "env_run_lists": { "production": [ "recipe[yyy::zzz]" ] } }
recipe
%w( bind-utils nagios-plugins nagios-plugins-all ).each { |name| package name } include_recipe 'mackerel-agent' include_recipe 'mackerel-agent::plugins' package 'mackerel-check-plugins'
package
は環境に合わせてよしなにyum install
やapt-get
に置き換えてくれるinclude_recipe
は、recipe
を取り込む。- 依存するrecipeは、#{COOKBOOK}/metadata.rb} に書き込む必要がある
- 外部cookbookも使える
attribute
上書きされる順番は弱い順にAttribute→recipe→Environment→Role。
Attributeの強さは弱い順にdefault→force_default→normal→override→force_override→automatic。
Berkshelf
外部クックブックのインストール管理できるbundlerみたいなやつ。
Berksfile
に参照するcookbookを書いて、以下でインストールできる。
# vendor/cookbooks ディレクトリにインストールする例 berks vendor vendor/cookbooks
外部クックブックはここにまとめてある。 https://supermarket.chef.io/
DryRun
# --why-run オプションで DryRun が実行される。 # 実行結果に Would xxxx と緑で表示されるのが、実際に実行される処理。 bundle exec knife zero converge 'name:node_name' -a ipaddress --why-run
chefのバージョンアップ
bundle exec knife zero converge 'name:#{SERVER_NAME}' -a ipaddress --why-run --client-version 13.12.14
gem install
サーバ内でChefRuby用のgemを直接インストール
sudo /opt/chef/embedded/bin/gem list | grep xxx sudo /opt/chef/embedded/bin/gem install xxx
参考
Terraform覚え書き
滅多に使わなくて忘れると思ったので。
terraform install
tfenvでバージョン切り替えできる
コマンド
# 必要となるpluginをインストールする。 terraform init # 設定ファイルが正しいかチェック/本番環境との差分出力 terraform plan # チェックの通った設定ファイルを本番環境に適用する terraform apply
- tfstateファイルはapplyのたびに生成される、現在の環境状態を表したJSONファイル。
設定ファイル
# 設定ファイルの拡張子は *.tf # providerにはawsやopenstackが入る provider "xxx" { } # 実際に作成するリソースを定義する resource "aaa(リソースの種類)" "bbb(リソースの名前)" { }
- terraformがビルドに使うのはカレントディレクトリにある.tfファイル
- リソースの種類は、プロバイダーがAWSの場合はaws_*という名前でTerraformで予め定義されています。VPCであればaws_vpc、EC2であればaws_instanceです。
変数の定義と参照
variable "access_key" {} variable "secret_key" {} provider "aws" { access_key = "${var.access_key}" secret_key = "${var.secret_key}" region = "ap-northeast-1" }
変数代入は下記3種あり
- オプション渡し
- 環境変数渡し
- ファイルで定義 (terraform.tfvars, variables.tf)
output
outputを指定することで、terraformコマンド実行時に指定した属性値がコンソール上に出力できる。
output "public ip of cm-test" { value = "${aws_instance.cm-test.public_ip}" }
Module
モジュールの定義
# modules/VPC/main.tf variable "vpc_cidr_block" {} variable "vpc_name" {} resource "aws_vpc" "this" { cidr_block = var.vpc_cidr_block instance_tenancy = "default" enable_dns_hostnames = true tags = { Name = "${var.vpc_name}-vpc" } }
モジュールを組み込む側
# module.tf module "vpc_hoge" { source = "./modules/VPC" vpc_cidr_block = "10.0.0.0/16" vpc_name = "hogehoge" }
- これで、
./modules/VPC/main.tf
で定義された resource をベースにしたモジュールができる。 - 参照先にresourceが複数ある場合は、module読み込みで全部作成される。
- 指定した値(vpc_cidr_blockやvpc_name)は、module内の変数に渡される。
同じリソースを複数作る
resource "openstack_compute_floatingip_associate_v2" "example" { count = "${var.example_count}" floating_ip = "${element(openstack_networking_floatingip_v2.example.*.address, count.index)}" instance_id = "${element(module.example.ids, count.index)}" }
- countは、作成するリソースの数。
- elementは、
element retrieves a single element from a list.
DataResources
リソースのデータを取得する。
以下の例では、data "openstack_networking_subnet_v2"
を使うことで、openstack_networking_subnet_v2 リソースのデータを取得できるようになる。
# 定義 data "openstack_networking_subnet_v2" "subnet" { name = "subnet_1" } # subnet_1のデータを参照する module "app" { cidr = "${data.openstack_networking_subnet_v2.subnet.cidr}" }
参考サイト
ctagsメモ
インストール
# メンテが止まっている # exuberant-ctags brew install ctags # こっちを使う # universal-ctags brew install --HEAD universal-ctags/universal-ctags/universal-ctags
設定
# ~/.ctags --append=yes --recurse=yes --php-kinds=cfd --ruby-kinds=cfm
- append=yes → tagsが既にあれば上書きではなく追加
- recurse=yes → 配下ディレクトリを再起的にタグ作成するかどうか(-Rと同じ)
- [言語]–kind → なんのタグを作成するかの設定(c=classなど)
設定の確認
ctags --list-maps ctags --list-kinds=ruby
.tagsの検索範囲を設定
vimでctagを使う場合に、カレントディレクトリからホームディレクトリまで .tags
を探す
# .vimrc set tags=.tags;~ # デフォルトはこちら # :set tags=./tags,tags
tagsファイルの作成
プロジェクトディレクトリに移動して
ctags -R --languages=Ruby -f .tags
で、プロジェクトディレクトリ直下に .tags ファイルが生成される。
- f → 出力ファイルを指定。デフォルトはtags
- R → 再帰的にファイルをチェックする
タグジャンプする
検索したいキーワードにカーソルを合わせて
CTRL-]
→ 現在のウィンドウでタグジャンプg CTRL-]
→ タグジャンプ先を候補表示するCTRL-w]
→ ウィンドウを分割してタグジャンプCTRL-t
→ タグジャンプ先から戻る
参考
SSL通信が成立するまで
SSL通信に関して理解が微妙だったのに雑にメモ。
SSL通信が成立するまで
- 秘密鍵は複合鍵
- 公開鍵は暗号鍵
- クライアントは共通鍵を作る。
- サーバの公開鍵で暗号化して共通鍵を受け渡す。
- その後の通信を共通鍵で暗号化して行う。
- link
デジタル署名
X.509
- 公開鍵基盤の標準仕様
- 公開鍵証明書の仕様も含まれる
- DER: 証明書をバイト列に落とし込んだもの
- PEM: バイト列をBASE64して修飾(——private key ——みたいなやつ)したもの
- link
p12ファイル
- 公開鍵・秘密鍵・クライアント証明書・中間CA証明書をひとつのファイルにまとめて取り扱えうための形式
- https://shinkufencer.hateblo.jp/entry/2019/07/12/000000
サーバのスペックをコマンドで確認する
現状のサーバのスペックを確認する必要があったので。
論理的なプロセッサ数を確認する
以下の場合は2個となる。
$ cat /proc/cpuinfo | grep processor processor : 0 processor : 1
物理的なプロセッサ数を確認する
以下の場合は、idが2つあるため2個
$ cat /proc/cpuinfo | grep "physical id" physical id : 0 physical id : 1
コア数を確認する
以下の場合は、1つのCPUにつき1コア
$ cat /proc/cpuinfo | grep "cpu cores" cpu cores : 1 cpu cores : 1
ディスク容量を確認する
$ df -h Filesystem Size Used Avail Use% マウント位置 /dev/vda1 50G 9.6G 41G 20% /
ディスクがSSDかHDDか
/sys/block/xxx/queue/rotational
で、対象のデバイスがディスクかどうか確認する事ができる。
返り値が1の場合HDD、0の場合はSSDを使用している。
$ cat /sys/block/vda/queue/rotational 1
ネットワークの帯域計算
帯域 ≒ (データ・サイズ * 2)÷ 所要時間 [bytes/s]
で計算できる。
$ ping -s 59992 xxx.example.com 60000 bytes from xxx.example.com (192.168.0.1): icmp_seq=41 ttl=62 time=1.71 ms ## 平均レスポンスタイム cat ping.txt | awk '{print $8}' | sed -e 's/time=//g' | awk '{sum+=$1} END {print sum/NR}' 1.85512
平均データ転送量
サーバが起動してからの転送量 / サーバが起動してからの時間
で算出できる。
# 転送量の確認 cat /proc/net/dev # サーバが起動してからの秒数(左側の値) cat /proc/uptime